OpenID Connect : Is it fine to use id_token as access_token?

Question

In one of the application at my work, we are thinking of just using id_token for all the use-cases including authentication and authorization. The solution is being developed from scratch right now. There are currently no consumers of any resources and we can modify the resources to use id_token. I am bit new to the concepts of openid_connect and oauth 2.0. Will there be any issue of just using id_token having all the access details?

Answer 1

ID tokens are meant to be read by the OAuth client. Access tokens are meant to be read by the resource server.

So if your server application is a backend for a frontend (such as JavaScript in browser, mobile app), the OAuth2 client role belongs to that frontend application, so the ID token should stay there and the frontend should not send it to its backend (resource server role). The frontend should send an access token to the backend. Then the backend can use the access token for various purposes:

• Read and validate it directly if it's in JWT form
• Use it for getting user info and scopes from the OAuth2 introspection endpoint if the token is just a random string
• Use the obtained info to allow/deny access to the requested resource (basend on scopes, roles, user or just validity of the token)

Access tokens are also useful for partial access delegation - when a user delegates some of their permissions (scopes) to an application with the OAuth client role. For example if I create an application that asks its users for a read-only access to their GMail, the application can get the access without it being allowed to access any other Google resources of the user.

Access token can be invalidated, ID tokens cannot. So in case of a suspicious activity, OAuth server may invalidate a token preventing its misuse. Resource server should find out about it when requesting the introspection endpoint.

Access tokens have a limited lifetime and an OAuth client must ask for new ones using a refresh token.

In case your application is just a simple server generating its HTML presentation and it has a role of an OAuth2 client (it initializes the auth request), the server can use the received ID token to read info about the authenticated user. Based on that, you can create a server side session to keep the user information and use a browser cookie for further authentication (not using OpenID Connect protocol).

Answer 2

I'd recommend following the OIDC spec as designed (i.e. use access_token rather than id_token for resource server authorization) to prevent opening yourself up to security vulnerabilities.

There's a good discussion here about using id_token as an access_token: https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147527823

The spec is designed for the id token to be used in the client and the access token to be used at the APIs. I'm sure you can come up with some alternative protocol to re-use the id token, but OAuth2 and OIDC just didn't evolve that way. I'm sure if they were all designed from scratch they'd look different.

As for "is it safe to pass the id token to the backend" -- not sure. I really haven't scrutinized the attacks against it or how it could be manipulated or fooled. The spec authors do that sort of thing, and that's why we tend to stick with their lead since they've spent many more hours on it then I have.

Question, why would you use id_token rather than access_token? It's easy to get a real access_token so why go against the spec?

Update:

If you do permit an id_token at the resource server (be warned), you need to whitelist each of the client "audiences" that you will allow to call your API, unless you want any application authenticated with your provider to call your API! Again, I'd recommend following the spec or you're going to create security vulnerabilities in the vacuum of solid guidance.

Answer 3

All authorization is local. What that means is that the server with the resource to be shared needs to have the information is needs to make the decision to release the resource, or not. So the question is; does the id_token have sufficient information with the required level of assurance to make the authorization or not. That is the only real question here.