OpenID Connect (OIDC)
An identity layer built on top of OAuth 2.0 that adds standardized user authentication, providing a verified identity token (ID token) alongside access delegation.
OpenID Connect (OIDC) extends OAuth 2.0 to solve the authentication problem that OAuth alone doesn't address. While OAuth 2.0 tells an app what a user allowed it to do, OIDC tells the app who the user is. It adds an ID token (always a JWT) containing identity claims like sub (subject identifier), email, name, and picture. OIDC also standardizes a UserInfo endpoint, discovery metadata (.well-known/openid-configuration), and dynamic client registration. Every major identity provider (Google, Microsoft, Okta, Auth0) supports OIDC, making it the de facto standard for federated login on the web.
Security Model
OIDC inherits OAuth 2.0's security model and adds ID token signature verification, nonce-based replay protection, issuer and audience validation, and standardized key discovery via JWKS. Security depends on TLS, proper token validation by the client, and the trustworthiness of the OIDC provider. The ID token signature guarantees the identity claims haven't been tampered with.
Implementation
medium complexityUser Experience
Identical to OAuth 2.0 from the user's perspective -- redirect to provider, authenticate, consent, redirect back. The difference is invisible to users but critical for developers: the application now receives a standardized identity. Users benefit from SSO -- once signed in to Google, all OIDC-integrated apps recognize them instantly.
Platform Examples
One of the original OIDC providers. Supports full OIDC discovery, ID tokens with rich claims, and Google-specific extensions like hosted domain restriction for Workspace customers.
Microsoft Entra ID
Enterprise OIDC provider supporting multi-tenant apps, B2B federation, and conditional access policies. Issues ID tokens with group membership and role claims.
Okta
Enterprise identity platform built on OIDC. Supports custom authorization servers, fine-grained claims mapping, and adaptive MFA tied to authentication context.
Auth0
Developer-focused OIDC provider with Universal Login, social connection aggregation, and Rules/Actions for custom ID token enrichment.
Tradeoffs
Strengths
- Standardized authentication on top of OAuth 2.0 -- solves the 'OAuth for login' anti-pattern
- ID tokens provide verifiable identity claims in a compact JWT format
- Discovery and JWKS enable automated, dynamic client configuration
- Interoperable across providers -- switch from Google to Okta without code changes
- Supports advanced features: session management, dynamic registration, claims requests
Weaknesses
- Adds complexity on top of an already complex OAuth 2.0 stack
- ID token validation has many steps that must all be correct for security
- Provider dependency -- your authentication is only as reliable as your OIDC provider
- Mapping identities across providers requires careful account linking logic
- Front-channel logout is unreliable in practice (depends on browser behavior)
Likely Follow-Up Questions
- What's the difference between an ID token and an access token? Who consumes each?
- How does OIDC discovery work and why is it important for multi-provider support?
- Walk through ID token validation -- what checks must the client perform?
- How would you implement federated login supporting Google, Apple, and email/password?
- What is the BFF pattern and why is it recommended for SPAs using OIDC?
- How does OIDC handle session management and logout across multiple applications?
Related Auth Methods
Source: editorial — OIDC deep dive covering the identity layer, token validation, enterprise patterns, and comparison with SAML for interview preparation.