[krooj]

Yup - OIDC can be boiled down to:

1. The OG OAuth2 spec never said anything about identifying principals 2. OIDC mandated an id_token to avoid the hit of POSTing the access token to an introspection endpoint 3. The shape of the id_token is a JWT

This doc is junk, btw - it's suggesting the client use the id_token for the purposes of authentication? I wouldn't trust that token beyond some basics, unless you have very strong controls over the authorization server and IdP to ensure things like email verification are propagated correctly.

[dwaite]

> OIDC mandated an id_token to avoid the hit of POSTing the access token to an introspection endpoint

A bit more fundamental than that, the two tokens are meant for different purposes and different audiences.

The access token is meant for delegated authorization of a user against resources. A client isn't even meant to be able to interpret it (but often can, because they are often signed JWTs). In particular, clients aren't supposed to use the introspection endpoint.

The id_token is meant for the client itself, about the user. This isn't meant to be shared with anyone other than the client, and must be audienced (only usable by the client).

Moreso, access tokens may be indefinitely long-lived access to resources, such as offline reading of a calendar for group scheduling free/busy information. An id_token is a signal at a particular point in time of state, e.g. this browser request represents this user because they bear the id_token.

[brewmarche]

To illustrate why OIDC introduced audience validation:

When you separately request user info from an endpoint with an access token (which according to OG OAuth2.0 is just an opaque string, which cannot be validated) that access token could be someone else’s, possibly from a user who logged into a different, malicious application which somehow managed to trick you into using that token