OpenID Connect (OIDC) is an identity authentication layer built on top of OAuth 2.0 that allows applications to verify who a user is and obtain basic profile information in a standardized way.

‍

Main takeaways

• OIDC adds authentication to OAuth's authorization framework: OAuth answers "what can this app access?"; OIDC answers "who is this user?"
• OIDC is the protocol behind most modern SSO implementations, enabling users to sign into applications using an existing identity from Google, Microsoft, Okta, or another identity provider.
• Because OIDC builds on OAuth 2.0, its security depends on correct implementation of token handling, redirect URI validation, and scope management—misconfiguration is a common source of vulnerability.
• OIDC-federated applications are only as governed as the identity provider behind them. Applications outside SSO—shadow SaaS, personal accounts—bypass OIDC entirely.
• Understanding OIDC is foundational to understanding how modern SSO, identity federation, and IdP coverage gaps work in practice.

What is OIDC?

OAuth 2.0 was designed for authorization—granting applications access to resources. But it deliberately left out a related question: who is the user making this request? That question requires authentication, and OAuth wasn't built for it. OIDC fills that gap by layering an identity verification mechanism on top of OAuth's authorization flows.

‍

In concrete terms: when a user clicks "Sign in with Google," the flow that follows is OIDC. Google acts as the identity provider, authenticates the user, and returns an ID token to the application—a signed assertion containing the user's identity and basic profile attributes. The application trusts Google's assertion without needing to manage or verify the user's credentials itself. This is federated identity in practice.

‍

How OIDC works

OIDC introduces several key components on top of OAuth:

• ID Token—A JSON Web Token (JWT) issued by the identity provider that contains claims about the authenticated user: their unique identifier, email address, name, and other attributes the application requested.
• UserInfo Endpoint—An API endpoint the application can call, using the OAuth access token, to retrieve additional user profile information.
• Discovery Document—A standardized endpoint that identity providers publish to advertise their configuration, making it easier for applications to integrate without manual setup.

The application validates the ID token's signature against the identity provider's published keys, reads the user's identity from the token claims, and establishes a session. The user's credentials never leave the identity provider.

‍

OIDC vs. SAML vs. OAuth

These three standards are often confused because they overlap in purpose and are frequently used together:

• OAuth 2.0—An authorization framework. Governs what an application can access, not who the user is.
• OIDC—An authentication layer on top of OAuth. Answers who the user is, using OAuth's infrastructure for token delivery.
• SAML—An older authentication and authorization standard that uses XML assertions rather than JSON. More common in legacy enterprise SSO integrations; OIDC has largely displaced it for modern applications.

The governance implication

Applications integrated via OIDC inherit the identity provider's governance: centralized provisioning, MFA enforcement, session policy, and deprovisioning. This is a significant advantage—but it only applies to applications that use OIDC. Every application an employee accesses with local credentials, a personal account, or a direct email signup falls entirely outside OIDC governance. The gap between OIDC-governed applications and actual SaaS usage is where much of the identity risk in modern organizations lives.

‍

Learn how Nudge Security maps the full SaaS identity landscape—including applications outside IdP coverage →