Call APIs from Highly Trusted Applications

Call APIs from Highly Trusted Applications

Since the Resource Owner Password Grant (ROPG) flow involves the client handling the user's password, it must not be used by third-party clients. In this flow, the user's username and password are exchanged directly for an Access Token.

Only consider using it when there is a high degree of trust between the user and the application and when other authorization flows (such as redirect-based flows) are not available.

Instead, Auth0 recommends:

You can use the ROPG flow for your highly trusted applications to access APIs. In this flow the end-user is asked to fill in credentials (username/password), typically using an interactive form. This information is sent to the backend and from there to Auth0.

ROPG (defined in RFC 6749, section 4.3) can be used directly as an authorization grant to store the user credentials for future use, by exchanging the credentials for an Access Token, and optionally a Refresh Token.

Resource Owner Password Grant

  1. The end user enters the credentials into the application.
  2. The application forwards the credentials to Auth0.
  3. Auth0 validates the information and returns an Access Token, and optionally a Refresh Token.
  4. The application can use the Access Token to call the API on behalf of the end user.

In OAuth 2.0 terms, the web app is the Client, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.

How to implement the flow

For details on how to implement this using Auth0, see Implement the Resource Owner Password Grant.

Realm support

A extension grant that offers similar functionality with the Resource Owner Password Grant, including the ability to indicate a specific realm, is the

Realms allow you to keep separate user directories and specify which one to use to the token endpoint. For example, you may have an application where both employees and customers can log in but their credentials are kept in separate user directories. You can present a user interface with a dropdown containing Employees or Customers as realms (which would be connections in Auth0 dashboard). The realm value, along with the username and password credentials, will be submitted to the token endpoint. Auth0 will use the realm value to determine which directory (connection) to use when verifying the password.

For more information on how to implement this extension grant refer to Executing a Resource Owner Password Grant > Realm Support.


Due to the implied trust in these grants (a user providing his or her password to an application), the Access Token returned will include all of the available scopes defined for the audience API. An application can request a restricted set of scopes by using the scope parameter, or you can restrict the returned scopes by using a rule.


Rules will run for the Password Exchange (including the Password Realm extension grant). There are two key differences in the behavior of rules in these flows:

  • Redirect rules won't work. If you try to do a redirect by specifying context.redirect in your rule, the authentication flow will return an error.

If you wish to execute special logic unique to the Password exchange, you can look at the context.protocol property in your rule. If the value is oauth2-password, then the rule is running during the password exchange.

For details on how to implement this, see Customize the Tokens.

MFA support and anomaly detection

For details on how to implement multi-factor authentication (MFA), refer to Multi-factor Authentication and Resource Owner Password.

When using this flow from server-side applications, some anomaly detection features might fail because of the particularities of this scenario. For details on how to implement this, while avoiding some common issues, refer to Using Resource Owner Password from Server side.

Keep reading