OpenID Connect
OIDC.
An identity layer on top of OAuth 2.0 that adds authentication semantics, ID tokens, claims, and standardized identity flows, to the authorization framework.
OIDC was finalized in 2014 by the OpenID Foundation and has progressively replaced earlier OpenID protocols (OpenID 1.0, 2.0) as the dominant identity layer. By 2026 OIDC is the protocol of choice for modern SSO, mobile authentication, and federated identity, every major CIAM platform supports it as a relying party (consuming OIDC from external IdPs) and as an OpenID Provider (issuing OIDC tokens to applications).
Common questions
What is the difference between OIDC and OAuth 2.0?
OAuth 2.0 is an authorization framework: it grants an app permission to act on a user's behalf, but says nothing about who the user is. OIDC is a thin identity layer on top of OAuth that adds authentication: an ID token, a userinfo endpoint, and standard claims that tell you who logged in. Use OAuth for delegated access, OIDC when you need to log a user in.
Should I use OIDC or SAML for SSO?
For new integrations, prefer OIDC: it is JSON and REST based, friendly to mobile and single-page apps, and simpler to implement than XML-based SAML. SAML is still required when an enterprise customer's identity provider only speaks SAML, which remains common. A B2B CIAM should support both and let each customer choose.
What is an ID token?
An ID token is a signed JWT that OIDC issues to prove a user authenticated. It carries claims such as the subject identifier, issuer, audience, and expiry, plus optional profile claims like email and name. Unlike an access token, the ID token is meant for the client app to read, not to be sent to APIs as a credential.
Related terms
In the guides
Enterprise SSO: SAML vs OIDC, and How to Pick
SAML and OIDC are the two protocols that dominate enterprise SSO. A practical comparison, when each is the right answer, and the IdP-side considerations that determine the choice.
OAuth 2.1 Explained: What Changed and Why It Matters
OAuth 2.1 consolidates fifteen years of OAuth 2.0 practice into a single coherent specification. What it deprecates, what it requires, and how to migrate existing OAuth 2.0 code.