OpenID Connect Explained: How Modern Login Systems Actually Work

The Problem OpenID Connect Solves

Every time you click "Sign in with Google" or "Continue with GitHub," you're using OpenID Connect (OIDC) — a modern identity protocol built on top of OAuth 2.0. But what's actually happening behind that button? Understanding OIDC is essential for any developer building applications that need user authentication without managing passwords themselves.

Before OIDC, developers had to either build their own auth systems (risky, expensive) or cobble together OAuth 2.0 flows that weren't designed for authentication at all. OIDC standardized a clean, secure identity layer on top of OAuth's authorization framework.

OIDC vs. OAuth 2.0: What's the Difference?

This distinction trips up many developers:

• OAuth 2.0 is an authorization framework — it answers "Can this app access this resource on the user's behalf?"
• OpenID Connect is an authentication layer — it answers "Who is this user, and can I trust that claim?"

OIDC adds a critical element that OAuth lacks: the ID Token — a signed JWT that contains verifiable claims about the authenticated user.

The Core OIDC Flow (Authorization Code Flow)

The most common and secure OIDC flow works as follows:

1. User clicks "Sign in with X" — your app redirects the user to the identity provider (IdP) with a request containing your client ID, requested scopes, and a redirect URI.
2. User authenticates at the IdP — they enter credentials, complete MFA, or approve the request. Your app never sees the password.
3. IdP redirects back with an authorization code — a short-lived, single-use code is sent to your redirect URI.
4. Your server exchanges the code for tokens — a back-channel request to the IdP's token endpoint returns an ID Token, an Access Token, and optionally a Refresh Token.
5. Your app validates the ID Token — verify the JWT signature using the IdP's published JWKS, check the iss, aud, and exp claims.
6. User is logged in — extract the sub (subject) claim as the stable user identifier.

The ID Token: JWT Claims You Need to Know

Claim	Meaning	Required?
iss	Issuer — the IdP's URL	Yes
sub	Subject — a unique, stable user identifier	Yes
aud	Audience — must match your client ID	Yes
exp	Expiration time (Unix timestamp)	Yes
iat	Issued-at time	Yes
email	User's email address	No (scope-dependent)
nonce	Value to prevent replay attacks	If sent in request

OIDC Discovery: The .well-known Document

Every OIDC provider publishes a discovery document at /.well-known/openid-configuration. This JSON file tells your application where to find all the endpoints it needs — token endpoint, authorization endpoint, userinfo endpoint, and JWKS URI. Using this document instead of hardcoding URLs means your integration automatically adapts when the provider updates their infrastructure.

Common OIDC Scopes

• openid — Required. Signals this is an OIDC request and returns a sub claim.
• profile — Returns name, picture, and other profile claims.
• email — Returns the user's email address and email_verified status.
• offline_access — Requests a refresh token for long-lived access.

Security Best Practices

• Always use the Authorization Code Flow for server-side apps, or PKCE for SPAs and mobile apps.
• Always validate the ID Token signature, iss, aud, and exp. Never trust unverified tokens.
• Use a nonce to prevent token replay attacks in browser-based flows.
• Store tokens securely — use HttpOnly cookies on the server, not localStorage in the browser.

Conclusion

OpenID Connect is the backbone of modern federated authentication. By understanding the flow, the ID Token structure, and the discovery document, you can implement secure, standards-compliant login systems without reinventing the wheel — and without ever handling your users' passwords.