Clarification on token usage

Help
, , ,
2

In your described scenario the SPA is an OAuth2 client application and the backend API is an OAuth2 resource server. The way you map this to Auth0 configuration is by:

  • creating a client application record in the Clients section of your dashboard to represent your SPA (ensure you set the correct client type).
  • creating an API record in the APIs section of your dashboard to represent your backend API.

You then setup your SPA to perform an implicit grant request that is both:

  • an OpenID Connect end-user authentication request (the scope includes openid among other relevant OIDC scopes associated with particular end-user information and the response_type includes id_token).
  • an OAuth2 authorization request targeting your backend API (you include the audience parameter containing the API identifier value you configured during API creation in dashboard and the response_type includes token).

The above means a successful response will deliver an ID token meant to be consumed by the client application in order to know which end-user is associated with the completed authentication request and also an access token suitable to be sent to your own API. Since you included the audience parameter pointing to your own API the issued access token will be a JWT (in the future other token formats may also be supported) which means the API can also validate it and retrieve some end-user information from it without actually having to make individual calls to the authorization server.

Have in mind that by default the access token will only include the Auth0 user identifier so if you want to include a bit more information about the user in the token itself in order to not have to query it again by user identifier you can consider the use of custom claims; see the reference documentation for additional details on how to accomplish this.

In conclusion, the ID token is meant to be consumed solely by the corresponding client application so you should use access tokens when calling the resource server. Although the ID token is always a JWT because the specification mandates it, an access token can also use that format and currently it is the format that is used when Auth0 issues access tokens meant to be consumed by your own API.