OpenID Connect

OAuth delegates resource access without itself defining standardized end-user authentication information for a client. OpenID Connect names the provider and relying party and uses standard claims to convey that identity layer.

In its code flow, the client exchanges a returned code for a response containing an ID Token and validates it to obtain the subject identifier. An access token can instead call resources such as UserInfo; the two token purposes are not interchangeable.

References: [1]

Required ID Token claims include issuer, subject, audience, expiration and issue time. The subject is locally unique and never reassigned within its issuer; identical strings from different issuers do not automatically identify one user. Display names or email fields do not replace that binding.

The relying party checks the expected issuer and its client_id audience, along with applicable cryptographic and time validation. A requested nonce must be returned and matched. Parsing JSON does not establish that these checks succeeded.

References: [1]

A client can call UserInfo with an access token, but the provider may omit requested claims for privacy or other reasons. Requesting a profile scope does not guarantee every display field will be returned.

UserInfo must contain sub, which must exactly match the ID Token subject before its values are used. This prevents substituting another token’s profile for the authenticated user: federation still needs explicit bindings rather than accepting any returned profile object.

References: [1]