Why shouldn't I use IdToken as bearer token in an IDP context?

Viewed 967

I am using an IDP platform (here AWS Cognito but that could be Auth0, OKTA or Keycloak) and I was wondering why I was discouraged to use the ID Token as an authorization token.

To be more specific, I will not make use of a resource server with authorization delegation from a user to a third-party app. My IDP will just let me SSO all my users on my different applications. There is no scope to grant here, only authentication claims that each service will use to grant or refuse access to resources (like an email, user ID, or the roles).

I understand I could provide my application with the id token and then create some session for my user. By why shouldn't I use the id token itself as a stateless session token, given that its signature can be checked on each application's back-end ?

And if I should use an access token over the id token - can I replace scopes by roles ? Or how should I understand the scopes in a non-delegation context ("user is usign the app himself, not giving permission" vs "user is giving all scopes to the SPA front-end which is an application in itself")

By the way, I am recovering the tokens through code PKCE flow on the front end.

1 Answers

The ID token only contains details about the user and how the user authenicated. so its perfect for creating a longer lasting cookie session with the user. The default lifetime for and ID-token is very short as well, like minutes. You typically throw the id-token away after establishing the sesson. You should never ever pass the ID-token around to other services.

The access token is mean to give you access to the APIs that the token is intended for.

when the user signs in, you ask for acceess to certain scopes and the scopes selected (consented) by the user , then is included in the access token (as scopes and audience claims).

In theory you can pass the ID-token to an API, bits not how its supposed to work. See this and this for more details:

Related