CodeParkThe ID token is for the client. The access token is for the API.
ID token: It's a JWT whose aud (audience: who the token is meant for) is the client id. It tells the client who logged in, when and how.
Access token: It's for the resource server, meaning the API. It carries scopes and an audience for the API. The client should treat it as opaque: it should not read or depend on what's inside.
Why an API shouldn't accept ID tokens:
- The audience is wrong. Every app the user signed into holds an ID token for that user. If your API accepted them, any of those apps could call it as the user.
- ID tokens carry no scopes. So there's no record of what access the user gave.
The API should validate access tokens for its own audience and the expected issuer. It can do this in two ways:
- verify a JWT access token (the RFC 9068 profile)
- call the introspection endpoint (RFC 7662), which asks the authorization server if the token is valid
- The ID token's audience is the client, and it proves who logged in.
- The access token's audience is the API, and it carries scopes.
- Accepting ID tokens lets any client of the IdP (identity provider) call your API.
- The API checks aud and iss on access tokens.
- The API validates JWT access tokens directly or uses introspection.