OpenID Connect (OIDC)
An identity layer on top of OAuth. OAuth grants permission to call an API; OIDC returns a signed ID token that says who just logged in.
See it
What it is
OAuth 2.0 was built to hand out permission to call an API. It does not standardize authentication, which is the part people keep expecting from it: an access token says an app was granted access, not that a particular human just proved who they are, and treating one as proof of identity is how apps get impersonated. OIDC is the standardized authentication layer bolted on top: same redirect dance, but you add the 'openid' scope and get back an ID token, a signed JWT that always carries iss, sub, aud, iat, and exp, and may carry email, name, and friends depending on the scopes you asked for and what the provider chooses to release. It also standardizes discovery (/.well-known/openid-configuration), the JWKS key endpoint, and a /userinfo endpoint, which is why one library can talk to Google, Entra ID, Auth0, and Keycloak without custom code per vendor.
Reach for OIDC any time login is the goal: social login, enterprise SSO that does not require SAML, or your own auth server across several apps. Reach for plain OAuth only when you genuinely want delegated API access, like reading someone's calendar.
Gotcha: the ID token is for your app, the access token is for the API. Sending an ID token as a bearer token to a resource server is the classic mistake. Validate the ID token properly (signature against JWKS, issuer, audience, expiry, nonce) instead of base64-decoding it and believing the payload, and remember that an unverified 'email_verified: false' claim is not proof of anything.
Ask AI for it
Implement login with OpenID Connect: use the provider's /.well-known/openid-configuration for discovery and request scope 'openid profile email' with the authorization code flow plus PKCE. Before redirecting, generate a random state, a random nonce, and a PKCE code verifier, and bind all three to the initiating browser, either in a server-side login transaction record or in a short-lived HttpOnly, Secure, SameSite correlation cookie. On callback, verify state against that stored value first and abort if it is missing or does not match, then exchange the code plus verifier for tokens. Validate the ID token signature against the JWKS endpoint and check iss, aud, exp, and the nonce you generated before trusting any claim. Treat email and name as optional claims. Key the local user on iss + sub, use the access token only for API calls, and never send the ID token to a resource server.