This tutorial will help you call your own API using the Resource Owner Password Flow. If you want to learn how the flow works and why you should use it, see Resource Owner Password Flow.
Because the Resource Owner Password (ROP) Flow involves the application handling the user’s password, it must not be used by third-party clients.
Auth0 makes it easy for your app to implement the Password Flow (sometimes called Resource Owner Password Grant or ROPG) using the Authentication API. Keep reading to learn how to call our API directly.

​
Prerequisites

Before beginning this tutorial:
  • Register your Application with Auth0.
    • Select an Application Type of Regular Web Apps.
    • Add an Allowed Callback URL of {https://yourApp/callback}. This field cannot be undefined or an error message will be returned.
    • Make sure your Application’s Grant Types include Password. To learn how, read Update Grant Types.
    • If you want your Application to be able to use Refresh Tokens, make sure the Application’s Grant Types include Refresh Token. To learn how, read Update Grant Types. To learn more about Refresh Tokens, read Refresh Tokens.
  • Register your API with Auth0
    • If you want your API to receive Refresh Tokens to allow it to obtain new tokens when the previous ones expire, enable Allow Offline Access.
  • Set up a connection
  • Update or disable any rules, so they only impact specific connections. If you get an access_denied error while testing the Password Owner Resource Grant, this could be due to an access control rule.

​
Steps

  1. Configure tenant:Set the tenant’s default connection.
  2. Request tokens: Exchange your authorization code for tokens.
  3. Call API: Use the retrieved Access Token to call your API.
  4. Refresh tokens: Use a Refresh Token to request new tokens when the existing ones expire.
Optional: Explore sample use cases Optional: Configure realm support Optional: Configure MFA Optional: Configure attack protection

​
Configure tenant

The Resource Owner Password Flow relies on a connection that is capable of authenticating users by username and password, so you must set the default connection for the tenant.
  1. Go to Auth0 Dashboard > Tenant Settings, and scroll down to locate the Default Directory setting.
  2. Enter the name of the connection you would like to use. Make sure it is capable of authenticating users by username and password.

​
Request tokens

To call your API, you must first get the user’s credentials, typically through an interactive form. Once your application has the credentials, you must exchange them for tokens. To do so, you must POST to the token URL.

​
Example POST to token URL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=password \
  --data 'username={username}' \
  --data 'password={password}' \
  --data 'audience={yourApiIdentifier}' \
  --data scope=read:sample \
  --data 'client_id={yourClientId}' \
  --data 'client_secret={yourClientSecret}'
Parameters
Parameter NameDescription
grant_typeSet this to password.
usernameThe username entered by the user.
passwordThe password entered by the user.
client_idYour application’s Client ID. You can find this value in your Application Settings.
client_assertionA JWT containing a signed assertion with your application credentials. Required when Private Key JWT is your application authentication method.
client_assertion_typeThe value is urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Required when Private Key JWT is the application authentication method.
client_secretYour application’s Client Secret. Required when Client Secret is the application authentication method. Application Settings is Post or Basic. If your application is not highly trusted (for example, a SPA), then do not set this parameter.
audienceThe audience for the token, which is your API. You can find this in the Identifier field on your API’s settings tab.
scopeSpecifies the scopes for which you want to request authorization, which dictate which claims (or user attributes) you want returned. These must be separated by a space. You can request any of the standard OpenID Connect (OIDC) scopes about users, such as profile or email, custom claims conforming to a namespaced format, or any scopes supported by the target API (e.g., read:contacts). Include offline_access to get a (make sure that the Allow Offline Access field is enabled in the Application Settings).

​
Response

If all goes well, you’ll receive an HTTP 200 response with a payload containing access_token, refresh_token, id_token, token_type, and expires_in values: 
{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer",
  "expires_in": 36000
}
Validate your tokens before saving them. To learn how, read Validate ID Tokens and Validate Access Tokens.
Refresh tokens must be stored securely since they allow a user to remain authenticated essentially forever.

Resource Owner Password flow and standard scopes

Because providing a password gives full access, any password-based exchange gives access to all scopes. For example, if you include no API scopes in the request, all API scopes will be included in the Access Token. Similarly, if you include only the openid scope in the request, all openid standard OpenID Connect scopes will be returned. In these cases, the scope parameter will be included in the response and will list the issued scopes.

Get user information without an ID Token

If you need the user’s information, include the openid scope in your request. If the API uses RS256 as the signing algorithm, the Access Token will include /userinfo as a valid audience, which means you can use it to invoke the /userinfo endpoint and retrieve the user’s claims.

​
Call API

To call your API, the application must pass the retrieved as a Bearer token in the Authorization header of your HTTP request. 
curl --request GET \
  --url https://myapi.com/api \
  --header 'authorization: Bearer {accessToken}' \
  --header 'content-type: application/json'

​
Refresh tokens

You have already received a refresh token if you’ve been following this tutorial and completed the following:
  • configured your API to allow offline access
  • included the offline_access scope when you initiated the authentication request through the authorize endpoint.
You can use the to get a new access token. Usually, a user will need a new access token only after the previous one expires or when gaining access to a new resource for the first time. It’s bad practice to call the endpoint to get a new access token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. To refresh your token, make a POST request to the /oauth/token endpoint in the Authentication API, using grant_type=refresh_token.

​
Example POST to token URL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id={yourClientId}' \
  --data 'refresh_token={yourRefreshToken}'
Parameters
Parameter NameDescription
grant_typeSet this to refresh_token.
client_idYour application’s Client ID. You can find this value in your Application Settings.
refresh_tokenThe refresh token to use.
scope(optional) A space-delimited list of requested scope permissions. If not sent, the original scopes will be used; otherwise you can request a reduced set of scopes. Note that this must be URL encoded.

​
Response

If all goes well, you’ll receive an HTTP 200 response with a payload containing a new access_token, its lifetime in seconds (expires_in), granted scope values, and token_type. 
{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "token_type": "Bearer"
}
Validate your tokens before saving them. To learn how, read Validate ID Tokens and Validate Access Tokens.

​
Sample use cases

​
Customize tokens

You can use Actions to change the returned scopes of Access Tokens and/or add claims to Access and . (To learn more about Actions, read Auth0 Actions.) To do so, add the following Action, which will run after the user authenticates: 
exports.onExecutePostLogin = async (event, api) => {
  // Add custom claims to Access Token and ID Token
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modify the scope of the Access Token
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};
Scopes will be available in the token after the Action has run.
Auth0 returns profile information in a structured claim format as defined by the OpenID Connect (OIDC) specification. This means that custom claims added to ID tokens or access tokens must conform to guidelines and restrictions to avoid possible collisions.

​
Configure realm support

Auth0 provides an extension grant that offers similar functionality to the Resource Owner Password grant, but allows you to keep separate user directories (which map to separate connections) and specify which one to use during the flow. To use this variation, you must:
  • Set the grant_type request parameter to http://auth0.com/oauth/grant-type/password-realm.
  • Send an additional request parameter called realm, and set it to the name of the realm to which the user belongs. For example, if you have configured a database connection for internal employees named employees, and your user belongs to it, then set realm to employees.

Connections as realms

Any connection that supports active authentication can be configured as a realm, including database connections, passwordless connections, and AD/LDAP, ADFS, and Azure Active Directory enterprise connections.

​
Configure MFA

If you need to use the Resource Owner Password Flow, but require stronger authentication, you can add (MFA). To learn how, read Authenticate Using the Resource Owner Password Flow with MFA.

​
Configure attack protection

When using the Resource Owner Password Flow with , some features may fail. Some common issues, however, can be avoided. To learn more, read Avoid Common Issues with Resource Owner Password Flow and Attack Protection.

​
Learn more