OpenID Connect (OIDC)
An identity layer built on top of the OAuth 2.0 protocol.
Detailed Explanation
While OAuth is about *authorization* (what you can do), OIDC is about *authentication* (who you are). It introduces the 'ID Token,' which contains information about the user in a standardized JWT format. If OAuth is the 'valet key' that lets a mechanic drive your car, OIDC is the 'driver's license' that proves who you are.
Quick Summary
OpenID Connect is the standard way to do "login with X" on the modern web, an authentication layer on top of OAuth 2.0 that adds an ID token containing verified user claims.
Key Takeaways
- Adds an ID token (a signed JWT) alongside OAuth's access token, with claims like `sub`, `email`, `name`, `iat`, `exp`.
- Discovery via `/.well-known/openid-configuration` lets clients auto-find endpoints and signing keys.
- Standard scopes: `openid` (required), `profile`, `email`, `address`, `phone`.
- Validate ID tokens: verify signature against the JWKS, check `iss`, `aud`, `exp`, and `nonce`.
- OIDC providers (Google, Auth0, Cognito, Azure AD, Okta) handle the heavy lifting, federated identity becomes a few lines of config.
When to use it
- Social login ("Sign in with Google").
- Enterprise SSO when SAML feels too heavy and the IdP supports OIDC.
- Mobile and SPA logins using Authorization Code + PKCE.
- Federating identity across microservices via a central authorization server.
Common Mistakes
- Treating the access token as identity information, only the ID token's claims are guaranteed about the user.
- Skipping signature/issuer/audience validation; an unverified JWT is just JSON.
- Forgetting the `nonce` parameter, which prevents ID token replay.
- Confusing `sub` (stable user ID) with `email` (can change) when keying users in your database.
OpenID Connect (OIDC), Frequently Asked
Can I just decode the ID token client-side and trust it?
Only if you also verify the signature against the provider's JWKS and check the standard claims (iss, aud, exp, nonce). Decoding without verification is the most common OIDC bug, the token's payload is publicly readable and trivially forged.
Which user identifier should I store?
Use the `sub` claim, namespaced by `iss`. Emails change, get reassigned, and aren't unique across providers. The (issuer, subject) pair is the stable identity key.