Where to Store Tokens

Execute an Authorization Code Grant Flow

This tutorial will help you implement the Authorization Code grant. If you are looking for some theory on the flow refer to Calling APIs from Server-side Web Apps.

The Authorization Code is an OAuth 2.0 grant that regular web apps use in order to access an API. In this document we will work through the steps needed in order to implement this: get the user's authorization, get a token and access the API using the token.

Before beginning this tutorial, please:

Regular web apps

1. Get the User's Authorization

To begin an Authorization Code flow, your web application should first send the user to the authorization URL:


  • audience: The unique identifier of the API the web app wants to access. Use the Identifier value on the Settings tab for the API you created as part of the prerequisites for this tutorial.

  • scope: The Access Tokensscopes which you want to request authorization for. These must be separated by a space. You can request any of the standard OpenID Connect (OIDC) scopes about users, such as profile and email, custom claims that must conform to a namespaced format, or any scopes supported by the target API (for example, read:contacts). Include offline_access to get a Refresh TokensRefresh Token (make sure that the Allow Offline Access field is enabled in the API Settings).

  • response_type: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be code.

  • client_id: Your application's Client ID. You can find this value at your Application's Settings.

  • state: An opaque value the application adds to the initial request that Auth0 includes when redirecting back to the application. This value must be used by the application to prevent CSRF attacks. For more information, see State Parameter.

  • redirect_uri: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the code URL parameter. This URL must be specified as a valid callback URL under your Application's Settings.

For example:

The purpose of this call is to obtain consent from the user to invoke the API (specified in audience) to do certain things (specified in scope) on behalf of the user. Auth0 will authenticate the user and obtain consent, unless consent has been previously given.

Note that if you alter the value in scope, Auth0 will require consent to be given again.

Native/mobile apps

2. Exchange the Authorization Code for an Access Token

Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (code) from the previous step, you will need to POST to the Token URL:


  • grant_type: This must be authorization_code.
  • client_id: Your application's Client ID.
  • client_secret: Your application's Client Secret.
  • code: The Authorization Code received from the initial authorize call.
  • redirect_uri: The URL must match exactly the redirect_uri passed to /authorize.

The response contains the access_token, refresh_token, id_token, and token_type values, for example:

Note that refresh_token will only be present in the response if you included the offline_access scope AND enabled Allow Offline Access for your API in the Dashboard. For more information about Refresh Tokens and how to use them, see our documentation.

Security Warning

It is important to understand that the Authorization Code flow should only be used in cases such as a Regular Web Application where the Client Secret can be safely stored. In cases such as a Single-Page Application, the Client Secret is available to the application (in the web browser), so the integrity of the Client Secret cannot be maintained. That is why the Implicit Grant flow is more appropriate in that case.

Single-page apps

3. Call the API

Once the Access Token has been obtained it can be used to make calls to the API by passing it as a Bearer Token in the Authorization header of the HTTP request:

Don't store tokens in local storage

4. Verify the Token

Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request must be rejected.

For details on the validations that should be performed refer to Validate an Access Token.

Using cookies

Optional: Customize the Tokens

You can use Rules to change the returned scopes of the Access Token and/or add claims to it (and the ID Token) with a script like this:

Namespacing Custom Claims

Auth0 returns profile information in a structured claim format as defined by the OpenID Connect (OIDC) specification. This means that in order to add custom claims to ID Tokens or Access Tokens, they must conform to a namespaced format to avoid possible collisions with standard OIDC claims. You can add namespaced claims using Rules.

If you wish to execute special logic unique to the Authorization Code grant, you can look at the context.protocol property in your rule. If the value is oidc-basic-profile, then the rule is running during the Authorization Code grant.

If a backend is present

Keep Reading