OpenID Connect (OIDC)

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.

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

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