OpenID Connect (OIDC) adds an authentication layer on top of OAuth 2.0. OAuth tells you what an app is allowed to do; OIDC tells you who the user is. It's the protocol behind "Sign in with Google", "Sign in with Microsoft", and most modern enterprise SSO. Same flows as OAuth, plus a signed ID token that authoritatively identifies the user.
← Back to Securityopenid scope turns an OAuth flow into an OIDC flow. The auth server then returns an ID token (a signed JWT) alongside the access token.sub (subject — the user ID), iss (issuer), aud (audience — your client ID), exp (expiry), email, name./.well-known/openid-configuration. One URL gives you all the endpoints, supported flows, signing keys URI, and capabilities.jwks_uri in the discovery doc returns the public keys used to sign ID tokens. Your app fetches and caches them; rotation just works.Before OIDC, every social-login provider invented its own user-info endpoint and claim names. OIDC standardized them — sub, email, name, picture, locale — so the same code works against Google, Microsoft, Okta, Auth0, Keycloak, your enterprise IdP. Plug-and-play federation.
An OAuth access token says "the bearer can call this API." An OIDC ID token says "the user with this sub just authenticated at this issuer." It's signed; it has an audience; it expires. You verify it locally without calling the auth server again.
You don't hard-code endpoints. Point your library at https://accounts.example.com and it discovers everything. New IdP onboarding is one config line.
Once a user has authenticated at the OIDC provider, every other app that trusts the same provider gets seamless login. The basis of modern SSO — within a company, across SaaS, even across organizations via federation.
scope=openid email profile, a PKCE challenge, and a state param.redirect_uri with a code and the original state.code + PKCE verifier for tokens at Google's token endpoint.iss matches Google, aud matches your client ID, exp in the future, nonce matches the one you sent.sub as the user's stable ID, look up or create the user, issue your own session."It came from the redirect, it must be fine." No — verify the signature, the issuer, the audience, and the expiry. An ID token without validation is just a string an attacker can forge.
The ID token identifies the user. The access token authorizes API calls. They're different. Don't decode the access token to "see who the user is" — many auth servers issue opaque access tokens, and even when they're JWTs, the claims aren't guaranteed.
email Without email_verifiedSome providers let users self-assert email addresses without verification. If you key your account lookup on email and the IdP didn't verify it, attackers can claim other people's accounts. Always check email_verified; prefer sub as the primary key.
nonceGenerate a random nonce per login attempt; store it in the session; verify the ID token's nonce claim matches. This binds the ID token to the originating browser session, defending against replay.
If you accept logins from multiple IdPs, you must validate iss against an allow-list and key the user not by sub alone but by (iss, sub). Otherwise two tenants' users with the same sub collide.
OIDC is the right answer for almost every modern login flow:
Reach for SAML only when integrating with a partner that mandates it (typically older enterprise IdPs). For new builds, OIDC wins on simplicity, tooling, and JSON-everywhere ergonomics.