Confusion around how to use id_token and access_token

Help
,
1

I’ve put the specifics about my app at the end of this post.

This is the scenario which best explains my confusion:

When the client part of my application authenticate the user with Auth0, the response is an id_token and an access_token. The id_token is a JWT which I can parse with the jwt-decode JavaScript library and it contains some information on who the user is.

The access_token looks something like this: 15sn1HEigklptyZbck7T3Z8tc*******and from what I can tell I shouldn’t be able to parse anything from it, but I should use it to do authorized HTTP requests against my backend, by attaching it to the Authorization of requests. Is this correct?

However, looking at some samples on how to implement token verification in my API, most of them show how to decode the JWT from the Authorization header on the request. But the access_token isn’t a JWT - at least that’s not what I’m getting in my authentication response. How come?

I made a rough sketch on how I assume things should work.

  1. The client passes the credentials that the user entered to Auth0, which passes the request to the appropriate authorization provider (Google, LinkedIn, Database connection)
  2. The provider answers if the credentials are good and if so returns the users profile to Auth0
  3. Then Auth0 generates an access_token for the client and returns the profile (id_token) and access_token to the client
  4. The client passes the access_token to the backend with each request

Is this correct?

alt text

Some specifics about my app

I have a bunch of clients which all are SPAs:

  • Chrome extension
  • Web app
  • Mobile app

The backend API is a Node.js server.

My client in Auth0 only provide authentication against a Auth0 Database connection.

1 Like
2

Based on the information provided you have the following components you need to represent in your Auth0 account:

  • a back-end Node.js API that should be represented by adding an entry in the APIs section of the dashboard.
  • a web application implemented with a SPA framework that should be represented by adding an entry in the Clients section of the dashboard and configured with a SPA Client Type.
  • a mobile application implemented with a Javascript SPA framework that should be represented by adding an entry in the Clients section of the dashboard and configured with a Native Client Type. Even though you implement it with Javascript it sill is a native application so it has completely different characteristics when compared to a SPA web application.
  • a Chrome extension that should be represented by adding an entry in the Clients section of the dashboard and configured with a Native Client Type. Again, the extension is not technically a web application even it “runs” on the browser so it should be categorized as a native application.

In relation to your questions, you’re correct that the client application should only request an access token and then use it in requests to API (it should not make any assumptions about the format and/or try to parse it).

The client application can indeed use the ID token to get some information about the authentication operation, including user information, but it should only do so after validating the token. Decoding the token is not enough, the signature should be validated. the Auth0.js library allows for ID token validation so you should consider it.

In relation to the access token being a JWT; the access token format is an implementation detail between the authorization server (issuer) and the resource server API to which it is meant to (consumer). Depending on your request the issued access token may only be suitable to API’s provided by Auth0 service itself like the /userinfo endpoint. In this case the format does not need to be a JWT.

However, if you make a request stating that you want an access token suitable to call your own API that you defined in the dashboard (aka the request contains an audience parameter where the value matches your API identifier) then the issued access token will indeed be a JWT so that your own API can validate it by itself.

Further useful read:

1 Like
3

Thanks @jmangelo ! I looked through your post and noticed that indeed I’ve done some things wrong. I will look into the details of your post shortly.

4

Thanks @jmangelo ! I looked through your post and noticed that indeed I’ve done some things wrong. I will look into the details of your post shortly.

5

Hello @jmangelo, What is the API suppose to do with the access token then? “In relation to your questions, you’re correct that the client application should only request an access token and then use it in requests to API”

6

@jmangelo I forgot to mention that I also have an Outlook addin in which I use Auth0. Would that also be a Native Client? I does run in a Internet Explorer browser, but is only available through Microsoft Outlook.

7

Perhaps the server is supposed to validate the token and then process the request if the token is valid.