Skip to main content
To get a , you must include the offline_access scope when you initiate an authentication request through the /authorize endpoint. Be sure to initiate Offline Access in your API. For more information, read API Settings. For example, if you are using the Authorization Code Flow, the authentication request would look like the following: The refresh token is stored in session. Then, when a session needs to be refreshed (for example, a preconfigured timeframe has passed or the user tries to perform a sensitive operation), the app uses the refresh token on the backend to obtain a new , using the /oauth/token endpoint with grant_type=refresh_token. Once the user authenticates successfully, the application will be redirected to the redirect_uri, with a code as part of the URL: {https://yourApp/callback}?code=BPPLN3Z4qCTvSNOy. You can exchange this code with an using the /oauth/token endpoint. The response should contain an access token and a refresh token. 
{
      "access_token": "eyJz93a...k4laUWw",
      "refresh_token": "GEbRxBN...edjnXbL",
      "token_type": "Bearer"
    }
If you are requesting a Refresh Token for a mobile app using the corresponding Native Client (which is public), then you don’t need to send the client_secret in the request since it’s only required for confidential applications. Refresh Tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever. For more information on how to implement this using the Authorization Code Flow, refer to our tutorial, Call API Using the Authorization Code Flow. For other grants, see Authentication and Authorization Flows.

​
Customize MFA

Customizable MFA with the Resource Owner Password Grant, Embedded, or Refresh Token flows is in Early Access. By using this feature, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement. To learn more about Auth0’s release stages, read Product Release Stages. To participate in the early access, contact Auth0 Support.
Customizable MFA allows users to enroll and challenge with factors of their choice that are supported by your application. During authentication at the oauth/token endpoint, the response returns the mfa_required error that includes the mfa_token to use the MFA API and the mfa_requirements parameter with a list of authenticators: 
{
  "error": "mfa_required",
  "error_description": "Multifactor authentication required",
  "mfa_token": "Fe26...Ha",
  "mfa_requirements": {
    "challenge": [
      { "type": "otp" },
      { "type": "push-notification" },
      { "type": "phone" },
      { "type": "recovery-code" }
      { "type": "email"} //can only work with challenge
    ]
  }
}
Use the mfa_token to call the mfa/authenticator endpoint for a list of all factors the user has enrolled and match the same type your application supports. You also need to obtain the matching authenticator_type to issue challenges: 
[
  {
    "type": "recovery-code",
    "id": "recovery-code|dev_qpOkGUOxBpw6R16t",
    "authenticator_type": "recovery-code",
    "active": true
  },
  {
    "type": "otp",
    "id": "totp|dev_6NWz8awwC8brh2dN",
    "authenticator_type": "otp",
    "active": true
  }
]
Enforce the MFA challenge by calling the request/mfa/challenge endpoint. Further customize your MFA flow with Auth0 Actions. To learn more, read Actions Triggers: post-challenge - API Object.

​
Learn more