In these examples, we use the Authorization Code Flow to authenticate a user and request the necessary permissions (scopes) and tokens. To learn more about the Authorization Code Flow, read Authorization Code Flow. For details on the request parameters or to learn how to fully implement this flow, read our tutorial: Add Login to Regular Web Applications.

In this example, we want to authenticate a user and get user details that will allow us to personalize our UI. To do this, we want to get an ID Token that contains the user's name, nickname, profile picture, and email information.

1. Initiate the authentication flow by sending the user to the authorization URL:

   https://YOUR_DOMAIN/authorize?
     response_type=code&
     client_id=YOUR_CLIENT_ID&
     redirect_uri=https://YOUR_APP/callback&
     scope=openid%20profile%20email&
     state=YOUR_STATE_VALUE
   
   

   Was this helpful?Yes/No
   Notice that in this example:

   1. The response_type parameter includes one value:

      1. code: because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the ID Token we need for authentication.

   2. The scope parameter includes three values; the requested OIDC scopes:

      1. openid: to indicate that the application intends to use OIDC to verify the user's identity.

      2. profile: to get name, nickname, and picture.

      3. email: to get email and email_verified.

2. After the user consents (if necessary) and Auth0 redirects back to your app, request tokens. (To learn more, read Add Login to Regular Web Applications: Request Tokens.)

3. Extract the ID token from the response and decode it. You should see the following claims:

   {
     "name": "John Doe",
     "nickname": "john.doe",
     "picture": "https://myawesomeavatar.com/avatar.png",
     "updated_at": "2017-03-30T15:13:40.474Z",
     "email": "john.doe@test.com",
     "email_verified": false,
     "iss": "https://YOUR_DOMAIN/",
     "sub": "auth0|USER-ID",
     "aud": "YOUR_CLIENT_ID",
     "exp": 1490922820,
     "iat": 1490886820,
     "nonce": "crypto-value",
     "at_hash": "IoS3ZGppJKUn3Bta_LgE2A"
   }
   
   

   Was this helpful?Yes/No
   Your app can now retrieve the user attributes and use them to personalize your UI.

In this example, we request a custom scope for a calendar API that will authorize the calling application to read appointments for the user. To do this, we want to get an Access Token containing the proper scope to read appointments from the API. Note that requesting an Access Token is not dependent on requesting an ID Token.

Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and define the scopes for your API using the Auth0 Dashboard. You can also use defined permissions to customize the consent prompt for your users.

1. Initiate the authorization flow by sending the user to the authorization URL:

   https://YOUR_DOMAIN/authorize?
     response_type=code&
     client_id=YOUR_CLIENT_ID&
     redirect_uri=https://YOUR_APP/callback& 
     scope=read:appointments&
     audience=YOUR_API_AUDIENCE&
     state=YOUR_STATE_VALUE
   
   

   Was this helpful?Yes/No
   Notice that in this example:

   1. The response_type parameter still includes one value:

      1. code: because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive the Access Token that we can use to call our API.

   2. the scope parameter includes one value; the requested API scope:

      1. read:appointments: to allow us to read the user's appointments from the API.

   3. The audience parameter is new and includes one value:

      1. The unique identifier of the API from which we want to read the user's appointments.

2. As in the previous example, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens. To learn more, read Add Login to Regular Web Applications: Request Tokens.

3. Extract the access token from the response, and call the API using the access token as credentials.

In this example, we combine our previous two examples to authenticate a user, request standard claims, and also request a custom scope for a calendar API that will allow the calling application to read appointments for the user. To do this, get two tokens:

• ID token that contains:

  • User name

  • Nickname

  • Profile picture

  • Email information

• Access token that contains the proper scope to read appointments from the API. Note that requesting an access token is not dependent on requesting an ID token.

Before using a custom API, you need to know what scopes are available for the API you are calling. If the custom API is under your control, you need to register both your application and API with Auth0 and define the scopes for your API using the Auth0 Dashboard. You can also use defined permissions to customize the consent prompt for your users.

1. Initiate the authentication flow by sending the user to the authorization URL:

   https://YOUR_DOMAIN/authorize?
     response_type=code&
     client_id=YOUR_CLIENT_ID&
     redirect_uri=https://YOUR_APP/callback& 
     scope=openid%20profile%20email%20read:appointments&
     audience=YOUR_API_AUDIENCE&
     state=YOUR_STATE_VALUE
   
   

   Was this helpful?Yes/No
   Notice that in this example:

   1. The response_type parameter still includes one value:

      1. code: because we are using the regular web app flow, our initial request is for an authorization code; when we request our tokens using this code, we will receive both the ID token we need for authentication and the access token that we can use to call our API.

   2. The scope parameter is used for both OIDC scopes and API scopes, so now includes four values:

      1. openid: to indicate that the application intends to use OIDC to verify the user's identity.

      2. profile: to get name, nickname, and picture.

      3. email: to get email and email_verified.

      4. read:appointments: to allow us to read the user's appointments from the API.

   3. the audience parameter includes one value:

      1. The unique identifier of the API from which we want to read the user's appointments

2. As in the previous examples, after the user consents (if necessary) and Auth0 redirects back to your app, request tokens.

3. Extract the ID token from the response, decode it, and retrieve the user attributes and use them to personalize your UI.

4. Extract the access token from the response, and call the API using the access token as credentials.

In this example, we add a user's favorite color and preferred contact method to the ID token. To do this, we create a rule to customize the token by adding these claims in a namespaced format. Once added, we will also be able to obtain the custom claims when calling the /userinfo endpoint (though the rule will run only during the authentication process). To learn more about rules, read Auth0 Rules. To learn more about namespacing, read Create Namespaced Custom Claims.

By default, Auth0 always enforces namespacing; any custom claims with non-namespaced identifiers will be silently excluded from tokens.

We do allow non-OIDC claims without a namespace for legacy tenants using a non-OIDC-conformant pipeline with the Legacy User Profile enabled, but we strongly recommend that legacy tenants migrate to an OIDC-conformant flow. 

Suppose that:

• The user logged in using an identity provider that returned a favorite_color claim as part of their user profile.

• At some point, the user selected a preferred_contact method of email, and we saved it as part of the user's user_metadata.

• We've used the Auth0 Management API to set application-specific information for this user.

In this case, the Auth0-stored normalized user profile is:

{
  "email": "jane@example.com",
  "email_verified": true,
  "user_id": "custom|123",
  "favorite_color": "blue",
  "user_metadata": {
    "preferred_contact": "email"
  }
}

(To learn more about the Auth0 normalized user profile, read Normalized User Profiles.)

For this profile, Auth0 would normally return the following ID token claims to your application:

{
  "email": "jane@example.com",
  "email_verified": true,
  "iss": "https://my-domain.auth0.com/",
  "sub": "custom|123",
  "aud": "my_client_id",
  "iat": 1311280970,
  "exp": 1311281970
}

Notice that in this example:

• The sub claim contains the value of the user_id property.

• Neither the favorite_color nor user_metadata properties are present because OpenID Connect (OIDC) does not define standard claims that represent favorite_color or user_metadata.

To receive the custom data, create a rule to customize the token with namespaced custom claims that represent these properties from the user profile. (To learn more about namespacing, read Create Namespaced Custom Claims.) Custom data will be available in the token after all rules have run.

function(user, context, callback) {
  const namespace = 'https://myapp.example.com/';
  context.idToken[namespace + 'favorite_color'] = user.favorite_color;
  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
  callback(null, user, context);}

This example shows custom claims being added to an ID token, which uses the context.idToken property. To add to an access token, use the context.accessToken property instead. To learn more, see Context Object in Rules.

When creating your rule, make sure to set some logic that determines when to include additional claims. Injecting custom claims into every ID token that is issued is not ideal.

With this rule enabled, Auth0 will include the favorite_color and preferred_contact custom claims in the ID token.

• OpenID Connect Scopes
• Create Namespaced Custom Claims
• API Scopes
• Set Logical API for Multiple APIs