ID Token and Access Token: What Is the Difference?

“Let’s use a token to secure this API call. Should I use the ID token or the access token? :thinking: The ID token looks nicer to me. After all, if I know who the user is, I can make better authorization decisions, right?”
Read more…

:writing_hand:t2: Brought to you by @andrea.chiarelli


What are you thoughts folks? Did you know the difference between both? Did you use it before?
Share in comments!

Hey, is something still unclear between ID and access tokens? Let me know!

1 Like

This is a really great infographic, and I like how you don’t just explain how to use them, but also how not to use them!

However, I would disagree that “you can’t make any assumption about the user’s identity” from an access token.

The infographic’s example access token shows a token issued by Auth0 with a client ID subject (sub) and client_credentials grant, meaning not only was an app authorized, it was also an app that did the authenticating! If this was a user-based flow, and the user (resource owner) has delegated their access to a particular application, that required a user authentication in order to authorize that app. I point this out to show that there is still very much a sense in which an access token does encode “authentication” information, because a client credentials flow, by OAuth2 definition, has a resource owner, such as you would get from the access_token’s “sub” claim (or, in the case of opaque tokens, somehow determinable by the resource server) because the resource server needs to know whose resources are being accessed. Of course, some APIs are entirely administrative, everything is specified by URL, and you don’t care about resource owners … but that’s not all APIs.

To quote Auth0’s own On The Nature of OAuth2’s Scopes, “a scope cannot allow an application to do more than what the user can do”—meaning knowing the user associated with the access token is (usually) pretty important!

(And in fact, Auth0’s extensibility is also super-helpful here, because we can add extra claims about that user/resource-owner … like an email address or employee identifier—to the access token. :wink: )

1 Like

Hey @emsearcy, thank you so much for your insightful comment. Actually, you’re right. That sentence is not well expressed :slight_smile:. I will change it.
Thanks again!

I am not sure if the sentence “do not send ID tokens to an API” is correct in every case.
What should I do if my resource server needs an authenticated identity (e.g. for logging?). Then I need an ID token … would I have to provide both tokens in this case?

Of course, everyone can do what they think is right :wink:
In a first-party scenario, you can choose to send an ID token to call an API, albeit with some potential risk.
In a third-party or delegated authorization scenario (the one for which OAuth was originally born), this is strongly discouraged for several reasons that I tried to explain in the article. Among these reasons:

  • the ID token does not contain authorization information (scopes) about what the application can do on behalf of the user
  • the user has not given consent to the application to use the ID token for that purpose

If your API needs the user’s information to make authorization decisions, your access token should provide it. For example, if your access token is in JWT format, you can provide additional claims.
After all, this is the reason behind the JWT Profile for OAuth 2.0 Access Tokens specification.

1 Like