# OpenID Connect (OIDC)
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that enables clients to verify user identity based on authentication performed by an authorization server. It adds a standardized ID Token (a signed JWT) to the OAuth flow, providing both authentication and basic profile information in a single protocol.
OIDC exists because OAuth 2.0 solves authorization (what can you access?) but not authentication (who are you?). OAuth 2.0's access tokens tell you nothing about the user who granted them. An access token might be valid for accessing a user's photos, but the application receiving that token has no standardized way to determine which user those photos belong to. OIDC fills this gap by introducing the ID Token, a cryptographically signed assertion about the authentication event and the authenticated user.
The protocol emerged from real-world implementation pain points. Before OIDC, every OAuth 2.0 provider handled user identification differently. Google used one endpoint and token format for user information. Facebook used another. Microsoft used a third approach. Application developers had to write custom integration code for each provider, creating security inconsistencies and implementation complexity. OIDC standardizes this process while maintaining OAuth 2.0's authorization capabilities.
OIDC fits into the broader identity ecosystem as the de facto standard for federated authentication. It bridges enterprise identity providers (Active Directory, LDAP) with cloud applications, enables consumer applications to authenticate users through social identity providers, and powers single sign-on across organizational boundaries. Unlike SAML, which requires XML processing and complex certificate management, OIDC uses JSON and HTTP, making it accessible to modern web and mobile applications.
OIDC extends OAuth 2.0 by introducing three core components: ID Tokens, the UserInfo endpoint, and standardized discovery mechanisms. The protocol supports multiple flows, but the Authorization Code flow with PKCE (Proof Key for Code Exchange) represents current best practice for most implementations.
The flow begins when a client application redirects the user to the OIDC provider's authorization endpoint. This request must include the openid scope alongside any additional scopes for user information or resource access. For example:
https://provider.example.com/auth?
response_type=code&
client_id=abc123&
redirect_uri=https://app.example.com/callback&
scope=openid profile email&
state=random-state-value&
nonce=random-nonce-value&
code_challenge=sha256-hash&
code_challenge_method=S256The state parameter prevents CSRF attacks. The nonce prevents ID Token replay attacks. The code_challenge and code_challenge_method implement PKCE, protecting against authorization code interception.
After user authentication, the provider redirects back to the client with an authorization code. The client exchanges this code for tokens at the provider's token endpoint, including the code verifier for PKCE validation. The response includes an access token, an optional refresh token, and crucially, an ID Token.
The ID Token is a JSON Web Token (JWT) containing claims about the authentication event and the user. Standard claims include:
iss (issuer): The OIDC provider that issued the tokensub (subject): A unique identifier for the authenticated useraud (audience): The client ID for which the token was issuedexp (expiration): When the token expiresiat (issued at): When the token was issuednonce: The nonce value from the original requestauth_time: When the user authentication occurredAdditional claims may include email, name, and other profile information depending on the requested scopes.
Token validation is critical. The client must verify the JWT signature using the provider's public keys (obtained from the JWKs endpoint), confirm the issuer matches the expected provider, ensure the audience contains the client's ID, check that the token has not expired, and verify the nonce matches the original request value.
OIDC providers expose a discovery document at /.well-known/openid_configuration that lists endpoints, supported scopes, signing algorithms, and other capabilities. This enables dynamic client configuration and reduces integration complexity.
For additional user information beyond what fits in the ID Token, clients can query the UserInfo endpoint using the access token. This endpoint returns claims about the authenticated user in JSON format, allowing applications to retrieve profile information without storing user credentials.
OIDC supports several flow types beyond Authorization Code. The Implicit flow returns tokens directly from the authorization endpoint but is deprecated due to security concerns. The Hybrid flow combines elements of both but adds complexity without clear benefits. The Authorization Code flow with PKCE addresses security concerns while maintaining implementation simplicity.
The protocol also defines logout mechanisms. RP-initiated logout allows clients to redirect users to the provider's logout endpoint, terminating the provider session. Front-channel and back-channel logout enable providers to notify clients when a user session ends, allowing coordinated logout across multiple applications.
OIDC has become the foundation for modern identity federation, powering everything from consumer social login to enterprise single sign-on. Its business impact extends beyond technical convenience to fundamental changes in how organizations approach identity management.
For businesses, OIDC enables identity outsourcing to specialized providers. Rather than implementing password policies, credential storage, multi-factor authentication, and account recovery workflows, applications can delegate these responsibilities to Google, Microsoft, Auth0, or enterprise identity providers. This reduces development costs, improves security posture (by relying on providers with dedicated security teams), and enhances user experience through familiar login interfaces.
The economic implications are significant. Password reset requests cost organizations between $20-$70 per incident when factoring in help desk time and user productivity loss. For a 1,000-employee organization, password-related support can exceed $100,000 annually. OIDC federation shifts this cost to the identity provider while often improving security through stronger authentication mechanisms.
However, OIDC implementations frequently fail due to incomplete understanding of security requirements. The most common vulnerability is insufficient ID Token validation. Applications that accept ID Tokens without verifying signatures, checking audience claims, or validating issuers are susceptible to token forgery and substitution attacks. An attacker who obtains an ID Token issued for a different application can potentially authenticate to vulnerable services.
Nonce handling presents another failure point. The nonce prevents replay attacks by ensuring each ID Token can only be used once. Applications that fail to generate unique nonces, store them securely, or validate them during token processing remain vulnerable to authentication replay attacks.
Redirect URI validation failures enable authorization code interception. OIDC providers must enforce exact redirect URI matching, and clients must register only necessary redirect URIs. Loose validation allows attackers to redirect authorization codes to attacker-controlled endpoints.
Session management complexity often undermines OIDC security benefits. Applications must decide whether to maintain their own sessions, rely entirely on the identity provider's session, or implement hybrid approaches. Poor session management can lead to scenarios where users appear authenticated to the application but their provider session has expired, or vice versa.
The misconception that OIDC eliminates all authentication security concerns leads to inadequate security controls. While OIDC provides strong authentication assurance, applications must still implement proper authorization, session management, and logout procedures. OIDC handles "who is this user" but not "what should this user be allowed to do."
CDA treats OIDC as the primary implementation of Zero Possession Architecture principles in the Identity, Authentication, and Trust (IAT) domain. Rather than possessing user credentials, applications trust external identity providers and verify every authentication claim through cryptographic validation.
This approach eliminates entire categories of risk. CDA applications cannot suffer credential database breaches because they store no credentials. They cannot implement weak password policies because they set no password policies. They cannot fail to implement multi-factor authentication because authentication occurs at the provider level. This represents a fundamental shift from defending stored credentials to validating external assertions.
CDA's Nexus platform demonstrates this philosophy by supporting only OIDC authentication through established providers (Google, GitHub, Microsoft, LinkedIn). This design choice reflects the IAT domain principle that identity assurance should come from specialized providers rather than application-specific credential systems. Each provider brings different strengths: Google provides broad consumer reach and strong mobile integration, GitHub offers developer-focused identity with repository access controls, Microsoft enables enterprise Active Directory federation, and LinkedIn provides professional identity verification.
The conventional approach treats OIDC as one authentication option among many, maintaining password-based fallbacks and custom credential systems. CDA differs by making OIDC the exclusive authentication mechanism, eliminating hybrid complexity and credential possession entirely. This creates operational simplicity (no password reset workflows, no credential storage, no authentication database maintenance) while improving security posture through provider specialization.
CDA's implementation enforces strict validation requirements that exceed typical OIDC deployments. All ID Tokens undergo server-side validation including signature verification, claim validation, and nonce checking. Redirect URIs use exact matching with no wildcards. Session management integrates OIDC authentication state with application authorization policies, ensuring consistent security controls across the platform.
The methodology extends to identity provider selection criteria. CDA evaluates providers based on security track record, availability guarantees, audit compliance, and operational transparency. This differs from conventional approaches that prioritize user convenience or business partnerships over security considerations. The goal is identity assurance, not user acquisition or vendor relationships.