OpenID Connect (OIDC) is an open standard for signing users in to applications through an identity provider. It is built on OAuth 2.0 and adds what OAuth on its own does not provide: a standard, verifiable way for an application to learn who the user is, along with details of the sign-in when the identity provider supplies them. That proof comes as an ID token, a signed JSON Web Token (JWT). OIDC is published by the OpenID Foundation and is one of the two main protocols behind enterprise single sign-on (SSO), alongside SAML.
At a glance
- Authentication on top of OAuth 2.0: OAuth grants access, OIDC adds identity.
- The identity provider returns a signed ID token identifying the user and describing the sign-in event.
- Uses JSON and REST conventions, which suit web, mobile and single-page apps.
- Common for enterprise SSO, consumer “sign in with” buttons and workload identity in cloud platforms.
- Handles sign-in, not account provisioning; accounts are commonly managed separately, for example with SCIM.
What problem it solves
Applications need to know who a user is. Building a separate login system for each one means separate passwords, inconsistent security and more places for credentials to leak. Delegating sign-in to a central identity provider (IdP) solves this, but the application needs a standard, secure way to receive and verify the result.
Before OIDC, some applications used plain OAuth access tokens as proof of identity. OAuth was not designed for that, and the approach led to security flaws, such as tokens issued for one app being accepted by another. OIDC fixes this with an ID token addressed to a specific application, signed by the identity provider and carrying standard details about the user and the sign-in. Compared with SAML, its JSON-based design is generally easier to use in mobile apps and modern web frameworks.
How it works
Registration. The application, called the relying party, is registered with the identity provider, which issues it a client identifier and, for server-side apps, a secret or other credential.
Sign-in request. When a user signs in, the app redirects the browser to the identity provider using an OAuth 2.0 flow, typically the authorization code flow with PKCE, and asks for the “openid” scope, which marks the request as OIDC.
Authentication. The identity provider signs the user in using whatever methods policy requires, such as passwords plus multi-factor authentication (MFA), passkeys or conditional access checks, or it reuses an existing session.
Tokens. The app exchanges the returned code for tokens: an ID token about the user and usually an access token for calling APIs.
Validation. The app checks the ID token’s signature using the identity provider’s published keys, and verifies the issuer, the audience (that the token is meant for this app), the expiry and, where used, a one-time value that helps prevent replay. If the app depends on how the user authenticated, for example requiring MFA, it should request and check the acr or amr claims, which not every identity provider sends.
User information. The app can read standard claims, such as name and email, from the ID token or from a user info endpoint. What the user may do inside the app is still decided by the app.
Discovery documents published by the identity provider let apps find its endpoints and keys automatically, which simplifies setup and key rotation.
When it matters for buyers
- When buying SaaS. Confirm the app supports OIDC or SAML single sign-on, and provisioning, on the plan you are buying.
- When building or commissioning applications. Use OIDC with your identity provider rather than a custom login; it keeps MFA and access policy central.
- When rolling out secure access. Many secure service edge services rely on SAML or OIDC with your identity provider to identify users before granting access.
- When choosing an identity provider. Check OIDC support for mobile, single-page and server apps, and for the cloud platforms you use.
Questions to ask vendors
- Do you support OpenID Connect, SAML or both, and on which plans?
- Which OIDC flows do you support, and do you use PKCE?
- Which claims do you read from the ID token, and can groups or roles be mapped?
- How long do sessions last after sign-in, and can they be revoked when we disable a user?
- Do you support automated provisioning, for example through SCIM?
- Can you request stronger authentication for sensitive actions, and do you check the acr or amr claims in the ID token?
How it differs from OAuth
OAuth 2.0 is an authorization framework. It answers “may this application access this API or resource?” by issuing access tokens, usually limited by scopes, and on its own it does not tell the application who the user is. OpenID Connect is an authentication layer on top of OAuth 2.0. It answers “who is this user?” with an ID token meant for the application, which can also carry the authentication time (auth_time) and method if the identity provider includes them. Apps that enforce session age need to request auth_time (for example with max_age) and validate it rather than relying on the token’s issue time. Because OIDC reuses OAuth’s flows, one sign-in can return both an ID token, for the app to identify the user, and an access token, for calling APIs. A rough rule: OAuth is about delegated access, OIDC is about sign-in, and Security Assertion Markup Language (SAML) is the older XML-based alternative for sign-in.