Overview
OpenID Connect (OIDC) is an identity layer built on OAuth 2.0 that adds standardized authentication to OAuth's authorization framework. While OAuth 2.0 answers "is this client authorized to access this API?", OIDC answers "who is this user?" by introducing the ID Token—a JWT containing user identity claims—and standardized endpoints for user information retrieval. OIDC powers "Login with Google/Microsoft/Apple" and enterprise SSO alike, providing a consistent protocol for applications to verify user identity regardless of the identity provider. The standard's discovery mechanism allows applications to automatically configure themselves by fetching provider metadata. Understanding OIDC is essential for modern IAM because it's the predominant protocol for authentication in web, mobile, and API contexts—it's what applications implement when they need to know who's logged in.
Architecture & Reference Patterns
Pattern 1: Authorization Code Flow with PKCE
The standard OIDC flow for web and mobile applications. The client redirects to the OpenID Provider (OP), receives an authorization code, and exchanges it for ID token, access token, and optionally refresh token. PKCE protects the code exchange. The ID token tells the client who the user is; the access token enables API calls. This is the recommended flow for virtually all applications.
Pattern 2: OIDC Federation (Enterprise SSO)
Applications (Relying Parties) federate with corporate identity providers via OIDC. Users authenticate at their organization's IdP (Azure AD, Okta, Ping) and access applications seamlessly. OIDC Discovery automates configuration—applications fetch .well-known/openid-configuration to learn endpoints, supported claims, and signing keys.
Pattern 3: Social Login Integration
Applications accept authentication from consumer identity providers (Google, Apple, Facebook, GitHub). Each social provider is an OpenID Provider; the application validates ID tokens and extracts user profile information. Account linking handles users who authenticate via different social providers at different times.
Pattern 4: OIDC Back-Channel Logout
When users log out of the IdP, it notifies all Relying Parties via back-channel logout requests. Applications terminate local sessions, ensuring consistent logout across federated applications. Essential for security-sensitive environments where session termination must be immediate and complete.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| OIDC flow | Authorization Code + PKCE, Implicit (deprecated) | Authorization Code + PKCE—always | Implicit is deprecated; hybrid flows rarely needed |
| ID token validation | Library validation, manual validation | Use verified OIDC library; never roll your own | Validation is complex and security-critical |
| Claims requested | Standard claims only, custom claims | Standard claims for interoperability; custom only when necessary | Custom claims may not be supported across providers |
| Discovery vs. manual config | Use discovery, manual configuration | Discovery for standard providers; manual only if discovery unavailable | Discovery reduces misconfiguration errors |
| Session management approach | RP-managed, IdP-managed, OIDC Session Management | RP-managed with back-channel logout | OIDC Session Management has poor browser support |
| Logout approach | Local only, front-channel logout, back-channel logout | Back-channel logout for security; front-channel as fallback | Front-channel logout is unreliable (blocked by browsers) |
Implementation Approach
Phase 0: Discovery
Inputs: Application inventory, current authentication methods, identity provider landscape, SSO requirements Outputs: Applications suitable for OIDC migration, IdP capability assessment, claims requirements per application, scope requirements, logout requirements
Phase 1: Design
Inputs: Discovery outputs, security requirements, UX requirements Outputs: OIDC architecture document, IdP selection/configuration, claims and scope mapping, session management design, logout flow design, error handling requirements
Phase 2: Build & Integrate
Inputs: Design documents, OIDC library selection, IdP configuration, test applications Outputs: IdP configured with client registrations, pilot applications integrated using OIDC libraries, ID token validation working, userinfo endpoint integration, back-channel logout implemented
Phase 3: Rollout
Inputs: Tested configuration, application migration plan, user communication Outputs: Applications migrated to OIDC in waves, legacy authentication deprecated, users transitioned, help desk equipped, monitoring operational
Phase 4: Operate
Inputs: Production OIDC environment, monitoring, security procedures Outputs: SLA maintained, new applications onboarded efficiently, IdP maintenance (key rotation, upgrades), security monitoring for token issues, continuous improvement
Deliverables
- OIDC architecture document with IdP and RP relationships
- Claims mapping document (what claims each application needs)
- Client registration standards and procedures
- OIDC library selection and integration guide
- Session management and logout design
- Monitoring and alerting requirements
- Troubleshooting runbook for OIDC issues
- Security checklist for OIDC implementations
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| ID token validation bypass | L | H | Security assessment findings, pen test results | Use verified OIDC libraries, never implement validation manually |
| ID token theft enables impersonation | M | H | Tokens in logs, stolen via XSS | Short token lifetimes, secure handling, audience validation |
| Key rotation breaks validation | M | H | Authentication failures, JWKS fetch errors | Monitor IdP key rotation, automatic JWKS refresh, caching with TTL |
| Logout incomplete (sessions remain) | M | M | Users finding themselves still logged in, security audit findings | Implement back-channel logout, test logout flows thoroughly |
| IdP outage blocks authentication | L | H | IdP status alerts, authentication failures | HA IdP, emergency procedures, monitoring |
| Misconfigured redirect URIs enable attacks | M | H | Security scans, pen test findings | Strict redirect URI validation, exact match only, no wildcards |
KPIs / Outcomes
- OIDC adoption: Percentage of applications using OIDC authentication
- Authentication success rate: Target over 99% for legitimate attempts
- ID token validation errors: Track and investigate validation failures
- Logout completeness: Back-channel logout delivery success rate
- Time to onboard new application: Should be straightforward with standard patterns
- Security incidents from OIDC misuse: Track and trend toward zero
