ID Tokens, Claims & OAuth2's Missing Piece

Authentication on Top of Authorization

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. OAuth2 alone only handles delegated authorization (granting access to resources); OIDC adds a standardized way to also verify who the user is, via a signed ID token — reusing OAuth2's flows rather than inventing a separate protocol.

ID Token vs. Access Token

// decoded ID token payload
{
  "iss": "https://accounts.example.com",
  "sub": "a1b2c3d4",
  "aud": "my-client-id",
  "exp": 1735689600,
  "email": "user@example.com"
}

The ID token (a JWT) proves the user's identity to the client — sub is the stable, unique user identifier to key a local record on, not something mutable like email. The access token, by contrast, authorizes calls to a protected API on the user's behalf. Using an access token to determine identity is a well-known pitfall — it's opaque/API-scoped, not a verifiable identity statement the way the ID token is.

Discovery & Signature Verification

A provider's .well-known/openid-configuration document describes its endpoints (authorization, token, userinfo, jwks), letting clients auto-configure rather than hardcoding URLs. The referenced JWKS endpoint publishes public signing keys — a client validates an ID token's signature against them, plus checks iss, aud, and exp, before trusting its contents.

The openid Scope & UserInfo

Including the openid scope in a request is what signals an OIDC (not plain OAuth2) request and triggers ID token issuance. The UserInfo endpoint lets a client fetch additional profile claims beyond the (often intentionally compact) ID token, using the access token from the same flow.