Konubinix' opinionated web of thoughts

ID Tokens vs Access Tokens

Fleeting

OIDC comes with the notion of id token. This is a JWT formatted token, and because a lot of authorization servers format the access tokens also using JWT, people tend to confuse both1.

This leads to people using id tokens as access token without thinking and other people shouting that this is something “YOU MUST NEVER DO!” without much thinking as well.

Let’s try to bring some nuance in here.

First, let’s not that some well known tools use the id token to get access to first party data2, 3. So we might be puzzled that even big actors don’t follow those recommendations.

Actually, it seems like authentication and authorization overlap a bit in several real life use cases. This is because is those use cases, the client and the resource server come from the same organisation, making it a first party client. See third-party vs first-party.

In that case, authentication is enough4, 5.

It seems like OAuth2 and self-encoded access token have been so much present in our life that we got them for granted and forgot to see how those fitted in our designs, hence the confusion when provided with several token about which one to use and what for6, 7, 8.

From that point, it seems like other people wanted to mitigate those misuses, but not with much more understanding of the context of the rfc.

For instance, they forgot about the 9 and get into the slippery slope of unconsciously think all sort of misuse10 that are not relevant in the first-party use case.

It is even forgotten that permissions can take a lot of forms and that access tokens are only one way to grant them11.

Hence, the common misconception that people use ID token as access token, while they might actually use ID Token as proof of authentication, using the bearer token transport12.

It follows that they poorly rationalize the “use only access token” point of view with vague considerations, such as “this is not meant to be used like that” or “it can lead to vulnerabilities… I don’t know which ones, but it certainly does”13.

Also, they guess some arguments on id tokens that actually also exist with access tokens14.

common mistake is to put them in local storage

— https://tcm-sec.com/id-tokens-vs-access-tokens-whats-the-difference/

following are common situations where you might send ID tokens to your server:

Sending ID tokens with requests that need to be authenticated. The ID tokens tell you the particular user making the request and for which client that ID token was granted

— https://developers.google.com/identity/openid-connect/openid-connect

One thing that makes ID tokens useful is that fact that you can pass them around different components of your app. These components can use an ID token as a lightweight authentication mechanism authenticating the app and the user. But before you can use the information in the ID token or rely on it as an assertion that the user has authenticated, you must validate it

— https://developers.google.com/identity/openid-connect/openid-connect

what if you want to flow the Identity of the user to the backed, and the API is part of your trusted ecosystem, then you, either: a. Add User Id, Name, Email, etc. claims to the access token(s)? or b. Pass the IdToken (as a bearer) through these layers?

— https://github.com/IdentityServer/IdentityServer3/issues/2015

access token is for the back end and it would contain the claims you need/want (or you could use the access token to call the user profile endpoint to look them up).

— https://github.com/IdentityServer/IdentityServer3/issues/2015

Access tokens are for APIs - feel free to send the id_token (or its contents) along - but treat it as payload.

— https://github.com/IdentityServer/IdentityServer3/issues/2015

If the OAUth2 and OIDC specs were re-designed today, maybe it’ll all be different and you could do this. But there’s history to how they were developed, and so it’s best if we stick to using them how they were designed so as we don’t introduce subtle security vulnerabilities into our apps

— https://github.com/IdentityServer/IdentityServer3/issues/2015

yes they are doing it wrong. All specs and threat models are clear on this. id_token is for the client, access token for the resource server. Now you might come up with a very specific scenario where using the tokens differently might be OK - but you are basically in uncharted territory (at least from a spec point of view)

— https://github.com/IdentityServer/IdentityServer3/issues/2015

there is a case where sending the ID token to a server, which I would not classify as a resource server, seems to make sense. This is when the ID token is used to authenticate and identify the user to another system. In this case the server, after verifying the token, would perform some action such as create an authenticated session or issue its own access token to provide API access against its resource server.

— https://github.com/IdentityServer/IdentityServer3/issues/2015

deontological point of view vs pragmatical point of view

Often, we see that “YOU SHALL NOT SEND AN ID TOKEN AS AUTHORIZATION TO THE API”1 because it is not meant for that. But alone, this does not weight much on the decision. If you face a case where it makes sense to do that, you’d better understand why not doing that and not just listen to method priests.

audiences: client vs resource server

The JWT payload of the ID Token is quite explicit, this is meant to be consumed by the client (called the relying party in OIDC) while the access token is meant to reach the 15, 1. When the later is self-encoded, its audience claim makes this even more explicit.

In some cases, where you have a SPA that consumes some resources from your server, the only think you need is a proof of authentication to get access to the resources of the user. When using an Identity Provider, you define an application and get a meaningless string as client id like “3faa352f-a50e-46a0-a286-b6a001f0fed5.apps.googleusercontent.com”. Deciding that the server and the frontend ARE the client and that therefore “3faa352f-a50e-46a0-a286-b6a001f0fed5.apps.googleusercontent.com” refers to both makes sense. Therefore, the argument about the audience appears to only become a semantic debate more than anything else.

usage: authentication vs authorization

When receiving an id token, you have a proof that a user authenticated, but that says nothing about whether or not this user has access to

ID tokens are conceptually analogous to ID cards, in that they contain a set of claims about the user, like name and email. This is different from an access token, which does not include any identifiable information and instead exists to authorize access to resource servers with limited scope

— https://goteleport.com/blog/how-oidc-authentication-works/

Access Tokens do not include any user information

— https://goteleport.com/blog/how-oidc-authentication-works/

Possession of the access token is not proof of authentication because access tokens can be acquired in multiple ways. Consider refresh tokens, which a client can exchange for another access token when the original is invalidated. This process occurs automatically between machines and does not involve the human user in any way, so the access token is not a proxy for authentication. ID tokens can only be obtained when the human user explicitly gives a client access to whatever information it requires. In other words, the user must go through the process of “Sign[ing] in with Google,” which only the account holder is capable of doing,assuming credentials have not been compromised

— https://goteleport.com/blog/how-oidc-authentication-works/

“Sender constraint” indicates a series of techniques that bind tokens to a particular sender

— https://auth0.com/blog/identity-unlocked-explained-episode-1/

two different specifications in the OAuth 2 family offering viable sender constraint capabilities today: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS, RFC8705) and OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP).

— https://auth0.com/blog/identity-unlocked-explained-episode-1/

MTLS is robust and stable, but not easy to implement

— https://auth0.com/blog/identity-unlocked-explained-episode-1/

DPoP quickly emerged as an easy to implement an alternative

— https://auth0.com/blog/identity-unlocked-explained-episode-1/

most common mistakes developers make with an ID token is using it to call an API

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

In a first-party scenario, i.e. in a scenario where the client and the API are both controlled by you, you may decide that your ID token is good to make authorization decisions: maybe all you need to know is the user identity

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

even in this scenario, the security

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

may be at risk

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

If an attacker manages to steal your ID token, they can use it to call your API like a legitimate client

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

access token, on the other hand, there is a set of techniques, collectively known as sender constraint, that allow you to bind an access token to a specific sender. This guarantees that even if an attacker steals an access token, they can’t use it to access your API since the token is bound to the client that originally requested it

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

In a delegated authorization scenario where a third-party client wants to call your API, you must not use an ID token to call the API

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

If your API accepts an ID token as an authorization token, to begin with, you are ignoring the intended recipient stated by the audience claim

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

  • You can still check it, make sure it was intended for YOUR client and your client alone.

API shouldn’t accept a token that is not meant for it. If it does, its security is at risk. In fact, if your API doesn’t care if a token is meant for it, an ID token stolen from any client application can be used to access your API

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

  • While this is true, it is not the only option. If the resource server checks that the token was indeed issued TO one of its known clients, that excludes the risk of accepting ALL the possible ID Tokens

your ID token will not have granted scopes

— https://auth0.com/blog/id-token-access-token-what-is-the-difference/

  • In the first-party scenario described above where the access is binary, that’s ok

Notes linking here

    • ID tokens are meant to be read by the OAuth client. Access tokens are meant to be read by the resource server.
    • ID tokens are JWTs. Access tokens can be JWTs but may also be a random string.
    • ID tokens should never be sent to an API. Access tokens should never be read by the client

    — https://oauth.net/id-tokens-vs-access-tokens/

     ↩︎ ↩︎ ↩︎

  2. how to reconcile the documentation from 0auth and Okta explicitly stating that ID Tokens should not be used as credentials to a Resource Server with Kubernetes explicitly providing a flow for doing so.

    — https://discuss.kubernetes.io/t/why-use-id-tokens-instead-of-access-tokens-for-authorization/27105

     ↩︎

  3. by the spec and the intent of the oidc spec writers okta is correct But that’s just not how it’s been used across APIs (not just kube) Defacto standards vs standards written

    — https://discuss.kubernetes.io/t/why-use-id-tokens-instead-of-access-tokens-for-authorization/27105

     ↩︎

  4. If you accurately described your issue in your question, you want authentication, so you should use ID Tokens.

    — https://security.stackexchange.com/questions/256061/oauth2-using-id-token-for-authentication-to-a-backend-service

     ↩︎

  5. What you describe is authentication, then authorization, in 2 steps. In your case, authorization is done with business logic, using the (previously authenticated) identity. Access Tokens are not suited for your needs, you should use only ID Tokens

    — https://security.stackexchange.com/questions/256061/oauth2-using-id-token-for-authentication-to-a-backend-service

     ↩︎

  6. our API endpoint receives a request with a token, then we first validate the token and extract user_id (authentication part) and second, we do some authorization logic (e.g. check that payment.owner_id == token.user_id), so actual authorization happens outside of OpenId/OAuth2, but we use user_id taken out of a token. And in this case either token works

    — https://security.stackexchange.com/questions/256061/oauth2-using-id-token-for-authentication-to-a-backend-service

     ↩︎

  7. people abuse ID tokens and access tokens all the time, in part because, at least until very recently, there was no standard for JWT formatted access tokens

    — https://community.auth0.com/t/why-cant-an-id-token-be-used-to-authenticate-an-api/62430

     ↩︎

  8. Identity wizards will likely balk at it but I don’t think there any significant harm, especially given this is all “in house”

    — https://community.auth0.com/t/why-cant-an-id-token-be-used-to-authenticate-an-api/62430

     ↩︎

  9. client that has no relationship with the resource server can access APIs of the resource server using an ID token that the client has legitimately obtained in an utterly irrelevant context.

    — https://darutk.medium.com/api-protection-by-id-token-3123481e96f2

     ↩︎

  10. user has granted a permission for the client to get an ID token, but she didn’t imagine that the permission would enable the client to call APIs of the irrelevant resource server.

    — https://darutk.medium.com/api-protection-by-id-token-3123481e96f2

     ↩︎

  11. possible options for API protection are just “all allowed” or “all denied”.

    — https://darutk.medium.com/api-protection-by-id-token-3123481e96f2

     ↩︎

  12. Some developers use ID tokens as access tokens, which is incorrect

    — https://tcm-sec.com/id-tokens-vs-access-tokens-whats-the-difference/

     ↩︎

  13. Misusing ID tokens this way can lead to vulnerabilities, such as unauthorized access to sensitive resources.

    — https://tcm-sec.com/id-tokens-vs-access-tokens-whats-the-difference/

     ↩︎

  14. if an ID token is intercepted and the system doesn’t validate it properly, attackers can impersonate users.

    — https://tcm-sec.com/id-tokens-vs-access-tokens-whats-the-difference/

     ↩︎

  15. they are two different tokens and do totally different things.

    and Importantly, we say that they have different audiences. […] the audience of an access token is the resource server, whereas the audience of the id token is the client application.

    —

     ↩︎