OpenID Connect (OIDC)

What is OpenID Connect?

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It exists to fix a specific, widely-misunderstood gap: OAuth 2.0 is an authorization framework (it grants an app permission to access resources), but it was never designed to tell an app who the user is. OIDC adds that missing identity layer in a standardized way, primarily via the ID token — a signed JWT containing verified claims about the user (their identifier, and optionally name, email, etc.). It’s what powers modern “Sign in with Google/Microsoft/etc.” and most contemporary federated identity for web and mobile.

OAuth vs OIDC — the distinction that trips everyone

This is the single most confused point in web security, so state it plainly: OAuth 2.0 is for authorization (“what can this app do?”), OIDC is for authentication (“who is this user?”). OAuth alone gives an app an access token to call APIs on the user’s behalf — but it deliberately says nothing standardized about the user’s identity. Developers who tried to do login with raw OAuth ended up inventing ad-hoc, insecure ways to infer identity from access tokens (the classic anti-pattern). OIDC standardizes it: alongside the OAuth access token, the provider issues an ID token — a JWT the app can cryptographically verify — plus a standard /userinfo endpoint. So the app authorizes with OAuth’s access token and authenticates with OIDC’s ID token. Using an access token as proof of identity remains a real vulnerability; the ID token is the right artifact for “who is this.”

Why it won and how it fits

OIDC became the modern default because it’s built on OAuth 2.0’s mature, widely-implemented foundation and uses JSON/JWT — far friendlier to web and mobile developers than SAML’s XML. It slots into the same Identity Provider / Service Provider model (OIDC calls them “OpenID Provider” and “Relying Party”), giving SSO across apps with centralized credentials. Practical security notes that matter: apps must validate the ID token’s signature (against the provider’s JWKS public keys), check its issuer, audience, and expiry, and use the right OAuth flow — the Authorization Code flow with PKCE is the current recommendation for web and mobile, while the old Implicit flow is deprecated for security reasons. SAML still dominates entrenched enterprise SSO, but OIDC owns new development.

What people get wrong

• Using OAuth access tokens as proof of identity — that’s the anti-pattern OIDC exists to fix; the ID token is the identity artifact.
• Skipping ID token validation: not verifying the JWT’s signature, issuer, audience, and expiry lets forged or misused tokens through.
• Using deprecated flows — the Implicit flow is out; Authorization Code with PKCE is the secure default for browser and mobile apps.

Primary source: OpenID Connect Core specification