OpenID Connect (OIDC)

What it is

OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0. Where OAuth gives an app delegated access, OIDC adds standardized authentication: it tells the app that a user logged in, when, how, and who they are. The core artifact is the ID token, a signed JWT the app validates locally. OIDC is the default protocol for modern single sign-on across consumer apps, mobile, SaaS, and workforce identity providers.

The normative text is OpenID Connect Core 1.0 incorporating errata set 2, dated 15 December 2023, by Nat Sakimura, John Bradley, Mike Jones, Breno de Medeiros and Chuck Mortimore.

Status (November 2026)

The ISO and ITU publications do not change the protocol. They matter for procurement and regulation in jurisdictions that require specifications from treaty-recognized standards bodies, which is the reason the OpenID Foundation gave for pursuing them. The OpenID Foundation's specifications page is the place to check which companion specs have ISO numbers.

How it works: the Authorization Code Flow

OIDC Core defines three flows. The Authorization Code Flow (response_type=code) is the one to use. Section 3.1 of the spec, in practice:

1. Discovery. The client (the "relying party") fetches the provider's metadata from /.well-known/openid-configuration to learn the authorization endpoint, token endpoint, userinfo endpoint, supported algorithms and the JWKS URI.
2. Authentication request. The client redirects the browser to the authorization endpoint with response_type=code, scope containing openid, client_id, an exactly registered redirect_uri, a state value, a nonce, and a PKCE code_challenge.
3. User authentication. The OpenID Provider authenticates the user (password, passkey, federation, whatever its policy demands) and obtains consent if needed.
4. Callback. The provider redirects back with a short-lived authorization code and the state.
5. Token request. The client sends the code and the PKCE code_verifier to the token endpoint over TLS, authenticating itself if it is a confidential client.
6. Tokens returned. The response carries an ID token, an access token, and optionally a refresh token.
7. Validation. The client validates the ID token (next section) and establishes its own session.
8. Userinfo (optional). The client calls the userinfo endpoint with the access token for additional profile claims.

The Implicit Flow (id_token or id_token token) returns tokens directly from the authorization endpoint, and the Hybrid Flow (code id_token, code token, code id_token token) returns some tokens there and some from the token endpoint. Both predate PKCE. The OAuth 2.0 Security BCP (RFC 9700) says clients should not use response types that issue access tokens in the authorization response, and OAuth 2.1 removes the implicit grant.

The ID token, and how to validate it

Required claims are iss, sub, aud, exp and iat. auth_time is required when max_age was requested, nonce is required when the request contained one, and acr, amr and azp are optional. The identity key is the pair iss plus sub, never email, which can change or be reassigned.

Section 3.1.3.7 lists the validation steps. The ones that matter most:

• iss must exactly match the issuer identifier from discovery.
• aud must contain your client_id; reject tokens listing audiences you do not trust.
• Verify the signature with the issuer's keys. The default alg is RS256 unless you registered another. A token received directly from the token endpoint over TLS may rely on TLS for issuer authentication, but most libraries verify the signature anyway, and you should too.
• exp must be in the future, and iat within your acceptable window.
• If you sent a nonce, the claim must be present and match.
• Check acr and auth_time when you asked for a level of assurance or a maximum age.

Common implementation mistakes and attacks

OIDC does not protect a user who completes a real login on a proxy: adversary-in-the-middle phishing captures the resulting session cookie regardless of protocol. That is an authenticator problem, solved by phishing-resistant MFA at the provider.

When to use it

Any time you need to log a user in. Reach for OIDC over raw OAuth for authentication, and over SAML when building modern web, mobile, or API-centric apps. SAML still wins where an enterprise customer's IdP only speaks SAML, which is why B2B products often support both.

Related standards

• OAuth 2.0 and OAuth 2.1: the authorization layer OIDC sits on.
• FAPI 2.0: a security profile of OAuth and OIDC for open banking and other high-value APIs.
• Shared Signals Framework: pushes session-revoked and account-disabled events between providers and apps after login.
• OpenID for Verifiable Credentials: issuance and presentation of credentials built on the same family.
• CIBA: decoupled authentication, where the user approves on another device.
• ID-JAG and Cross App Access: exchanges an OIDC ID token for access to another app's API.

Who implements it

Almost every identity provider and CIAM platform ships an OIDC provider. The OpenID Foundation runs a certification program; certified OpenID Provider entries we saw on 5 November 2026 include Auth0, ForgeRock, Keycloak, Curity, Gluu, authentik and Akamai Identity Cloud. Certification is per product version, so check the list for the release you run. For choosing a provider, see the CIAM buyer guide and the IAM buyer guide.

How to check an implementation

1. Decode a real ID token with the JWT decoder and confirm iss, aud, exp and nonce are what you expect.
2. Change one byte of the signature and replay it. Your app must reject it.
3. Re-sign the header as "alg": "none" with an empty signature. Rejected.
4. Send a token issued for another client ID. Rejected on aud.
5. Omit nonce from a callback where you sent one. Rejected.

How it works, message by message

The OIDC message-flow walkthrough shows each HTTP exchange of the authorization code flow with annotated values: discovery, the authentication request, the callback, the token request with PKCE, the token response and a decoded ID token, with every parameter tied to its OIDC Core or RFC section. Check a provider's metadata with the OIDC discovery checker.

Related

Guides: OAuth vs OIDC, SAML vs OIDC, implementing OAuth 2.0 and OpenID Connect, implementing SSO. Glossary: OIDC, ID token, claims, identity provider, relying party.

Who wrote it

OpenID Connect was authored by a group including Nat Sakimura, Mike Jones, and John Bradley. Vittorio Bertocci did much of the work of explaining it to developers, and Filip Skokan and Roland Hedberg maintain certified implementations. More in the experts directory.