We want to establish a secure authentication flow for between our API and client applications.
For this, we are thinking of using the resource owner password grant, wherein each user will provide their email and password, the backend application will exchange these credentials with Auth0 for the exchange of access_token.
This access_token will further be used for making secure API calls to the backend.
Please guide me, to figure out whether or not I have chosen the right methodology.
In general, the resource owner password credentials (ROPC) grant would be last resort option or the least recommended one for most cases. This grant is mostly useful when migrating legacy/proprietary authentication protocols to OIDC/OAuth 2.0 and either due to time constraints or to reduce risk you want to perform this migration in incremental steps with as few changes as possible in the first iteration.
For example, imagine you had a regular web application that collected end-user credentials, POSTed them to the server, the server would validate them against a local database and then initiate a cookie-based session. Moving from this scenario to one where the credentials are not managed locally but are instead managed through an OIDC/OAuth 2.0 identity provider/authorization server it’s very linear if you make use of ROPC.
Using ROPC in the above scenario would allow to move the credentials to the identity provider while performing minimal changes to the legacy application in the first iteration. However, if you’re building the full system from scratch there is very little reasons to consider ROPC; in this case I would recommend you to check the following link as a guide to decide which flow to use depending on the client application:
Thanks @jmangelo
To make the situation more clear, we have an existing backend software which was earlier established to work in sync with regular web applications.
As per our new requirement, we need to integrate Auth0 enabled authentication in this backend software for the applications interacting with the system.
Thus we opted for this solution after doing a bit of research through the Auth0 documentation. Just wanted to confirm if we are on the right track.
From your description of the situation you do seem to be in one of those situations where the system was already in place so considering ROPC as an initial step towards a migration to OIDC/OAuth 2.0 seems adequate and worthwhile as a first step. I would just add the additional note that ROPC will only available for certain Auth0 connections (like database connections); for example, social authentication would not be applicable so there could be other situation influencing the decision.
Thank you so much for your time and suggestions. It was very much needed.
I really appreciate it.