OpenID Connect (OIDC)
An identity layer on top of OAuth 2.0 that adds authentication: it issues an ID token (a JWT) proving who the user is, plus user info. It's the standard way to do single sign-on and 'Log in with X' with a real identity.
- Single sign-on and federated login.
- Any app needing verified user identity from an IdP.
- Pure machine-to-machine (use client credentials).
- When you only need authorization, not identity.
Definition
OIDC extends OAuth 2.0 with an ID token (a signed JWT with user claims), a userinfo endpoint, and standardized scopes (openid, profile, email). The client verifies the ID token to authenticate the user.
Why it exists
OAuth 2.0 is authorization only; using access tokens as proof of identity is insecure. OIDC adds a signed, verifiable identity assertion so clients can trust who logged in.
How it works
Same authorization-code flow as OAuth, but the token response includes an ID token. Client validates the JWT signature (JWKS), issuer, audience, nonce, and expiry, then trusts the claims to establish a session.
Scaling limits
JWKS fetching/caching for signature verification; key rotation must be smooth. Token replay mitigated by nonce and short lifetimes.
Cost shape
Same as OAuth plus JWKS distribution. ID tokens are self-verifying, so per-request auth is cheap.
Alternatives
- SAML — Enterprise SSO standard, XML-heavy and harder to implement.
- Self-rolled auth — Full control but you own all the security risk.
Failure modes
- Missing nonce validation enabling token replay.
- Not validating audience/issuer, accepting tokens minted for others.