Calling APIs from Highly Trusted Clients

Highly trusted mobile apps and Client-side web apps can use the Resource Owner Password Grant to access an API. In this flow the end-user is asked to fill in credentials (username/password) typically using an interactive form. This information is later on sent to the Client and the Authorization Server. It is therefore imperative that the Client is absolutely trusted with this information.


The Resource Owner Password Grant (defined in RFC 6749, section 4.3) can be used directly as an authorization grant to obtain an access token, and optionally a refresh token. This grant should only be used when there is a high degree of trust between the user and the client and when other authorization flows are not available.

This grant type can eliminate the need for the client to store the user credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.

Resource Owner Password Grant

  1. The Resource Owner enters the credentials into the client application
  2. The client forwards the Resource Owner's credentials to the Authorization Server
  3. The Authorization server validates the information and returns an access_token, and optionally a refresh_token
  4. The Client can use the access_token to call the Resource Server on behalf of the Resource Owner

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 a client), the access_token returned will include all of the available scopes defined for the audience API. A client 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 try to do MFA by specifying context.multifactor 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, refer to Execute the Resource Owner Password Grant: Customize the Tokens.

MFA Support

For details on how to implement multifactor authentication, refer to Multifactor Αuthentication and Resource Owner Password.

Use Case

  • Allow the Client to make calls to the Resource Server on behalf of the Resource Owner
  • The Client is a highly trusted application and other authorization flows are not available