Basic, Messages, Standard - Why can’t the ID token be used to call the UserInfo endpoint?

[Michael Jones]

Is there a reason that the UserInfo endpoint can't accept the ID Token as input rather than the Access Token? It's signed by the issuer and contains the user_id, therefore it should be possible for the UserInfo endpoint to return claims for the user identified by the user_id in the ID Token.

We should either say that this is possible or add clear rationale to the specs saying why it is forbidden.

[Nat Sakimura]

The semantics is different.

id_token has no association with the UserInfo claims release consent.

[John Bradley]

Add explanation no change to spec

[John Bradley]

The tokens have different audiences. The Access token's audience is the protected resource, and the id_token is the client.

For symmetrically signed tokens it would allow the client to modify the tokens going to the protected resource as the client has the secret for the HMAC.

The content of the tokens also generally needs to be different to protect privacy.

It is possible that you could have an optimization using asymmetrically signed tokens with multiple audiences if JWT supported that. The client would need to discover that the Authorization server supported that optimization.

The spec allows for the Access tokens to be opaque to the client, so that existing OAuth API can be used without requiring them to be rewritten for JWT.

This is a do not fix for the implementers draft.