OpenID Connect (OIDC)

What is OpenID Connect?

OpenID Connect (OIDC) is an authentication layer built on top of the OAuth 2.0 authorization framework. OIDC lets applications, known as relying parties, verify an end user's identity and obtain basic profile information from an identity provider, which OIDC calls an OpenID Provider.

OIDC works with a range of applications, from web apps and single-page applications (SPAs) to native and mobile apps. Organizations can also use OIDC to provide single sign-on (SSO) across apps.

OIDC relies on an identity provider to authenticate users. That provider can be a public service such as Google or Microsoft, or an enterprise identity provider that the organization manages. With OIDC, a user can access an application by signing in with a trusted, OIDC-compatible account.

How OIDC works

OIDC adds a standard identity layer to the OAuth 2.0 authorization code flow. In most applications, a sign-in works in seven steps:

The user selects Sign in on the application.
The application redirects the user's browser to the identity provider with an authentication request that includes the openid scope.
The identity provider signs the user in, with multi-factor authentication (MFA) if required, and ask for consent if needed.
The identity provider redirects the browser back to the application with a one-time authorization code.
The application exchanges the code for tokens by calling the identity provider directly, using a proof key for code exchange (PKCE) verifier to show the request came from the same application.
The identity provider returns an ID token and usually an access token.
The application validates the ID token and signs the user in.

The ID token is a signed JSON Web Token. It carries claims, or individual pieces of information, about the sign-in, such as the issuer (iss), the user's unique identifier (sub), the intended application (aud) and the issue and expiry times (iat and exp). The application verifies the signature using the keys the identity provider publishes and checks those claims before trusting the token.

Scopes such as profile and email allow the application to request additional claims about the user, and it can also call the provider's UserInfo endpoint to retrieve them.

OIDC defines other flows, but the authorization code flow with PKCE is recommended for most web apps, SPAs and mobile apps, and the older implicit flow is deprecated.

OIDC benefits and common uses

Single sign-on across applications

OIDC lets users sign in once with their identity provider and reach many applications without a separate login for each. The identity provider issues a signed token that identifies the user to each application.

Fewer passwords for applications to store

Applications that use OIDC never see or store passwords, since users authenticate at the identity provider. The provider can enforce controls such as account lockout, rate limiting and MFA in one place. OIDC does not stop brute force attacks on its own, but it concentrates that protection at a single login.

Fewer credentials to phish

Users sign in to applications through a trusted identity provider instead of creating a separate password for each one, which reduces the number of credentials a cybercriminal can target. Phishing the identity provider's login page is still possible, so phishing-resistant MFA at the provider matters.

Controlled sharing of user information

OIDC lets an application request only the claims it needs, such as a name and email address. The identity provider can show the user what the application requested and ask for consent. An application does not receive details such as a birthdate or home address unless it requests them and the user or an administrator approves.

Is OIDC still widely used?

Yes. OIDC is still widely used and supported by major identity providers. Newer authentication methods such as passkeys do not replace OIDC; they work with it, because the identity provider can use a passkey to authenticate the user and still issue OIDC tokens.

More resources

Blogs

What's the difference between authentication and authorization?

SAML vs. OAuth: What's the difference?

SAML vs. SSO: What's the difference and how they work together

Federated identity management vs. SSO