In OpenID Connect, is it okay to pass an id token instead of an access token to a resource server for authorization?

Question

I'm considering to use id token instead of id token for authorization, so that resource servers can validate its sign and extract user id out of it. Is there any dowside to this method which I'm not aware of?

I guess I cannot use verify endpoint if I throw away access token. For us, it doesn't matter which scope the user granted access to since both client app and OIDC's identity provider is owned by us.

I'm using this library to implement an OAuth2 and OpenID server. https://github.com/bshaffer/oauth2-server-php

Answer 1

Usage of ID Token is intended for the client application. Client uses it to authenticate the end user. All this is made possible through claims ID Token transfer. And these claims are built into an JWT. In simple terms, ID Token is a self-contained token.

Now, sharing of ID Token outside of client is okay if you control all intended parties. Think about a scenario in which you leak sensitive user information through ID Token. For example if ID Token contain a claim about gender which only intended for client to use. But when you share ID Token with a third party, you expose those sensitive information. It could be a crime if there are legal barriers.

Another point is on ID Token validation. Hence ID Token targets the client, important claims such as aud is set accordingly. When you pass ID Token to a backend to be used, such validation could fail.

There are two solutions. First is to use self contained access tokens. These days it is common to use JWT based access tokens. With them, you get the same solution. It will contain end user identity, scope values as well as token validation information. Azure AD use such approach - check this link.

Second one is to use ID Token. Given that you control both front end and backend, my opinion is you are okay to use it. But be mindful about future extensions. Specially not to expose it to other parties.