OpenID Connect

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that allows an application to verify who a user is, based on authentication performed by an identity provider, and to obtain basic profile information in an interoperable way. Its central artifact is the ID token, a signed JSON Web Token that states which user authenticated, at which provider, for which application and when.

In identity & access management, OpenID Connect fills a gap that OAuth 2.0 deliberately left open: OAuth grants authorization to call APIs, but it does not define how a client learns the user’s identity. OIDC standardizes that answer, which is why it underpins most modern single sign-on for web, mobile and cloud applications.

How the OpenID Connect flow works

The recommended OIDC flow is the authorization code flow with PKCE. The application, called the relying party, redirects the browser to the provider with the openid scope; the user authenticates there; the provider returns a short-lived code; and the application exchanges that code at the token endpoint for an ID token and usually an access token.

1. The relying party sends an authorization request with scope=openid, a state value, a nonce and a PKCE code challenge.
2. The OpenID provider authenticates the user, possibly with MFA or a passkey, and asks for consent if required.
3. The browser returns to the registered redirect URI with an authorization code.
4. The relying party exchanges the code and the PKCE verifier for tokens over a back channel.
5. The relying party validates the ID token and creates its own session for the user.

Because tokens travel over a direct server-to-server request, they never appear in the browser address bar. This is the main reason the older implicit flow is now discouraged.

The ID token and its claims

An ID token is a JWT signed by the provider, typically with RS256 or ES256, whose claims describe the authentication event. The relying party must verify the signature using keys published at the provider’s JWKS endpoint and then check the claims below.

A common error is identifying users by email address instead of the iss and sub pair. Emails can change or be reassigned, while the sub value is guaranteed stable for a given issuer.

Endpoints, scopes and discovery

OpenID Connect providers publish a discovery document at /.well-known/openid-configuration, which lists their endpoints, supported algorithms and scopes. Client libraries read it automatically, which removes most manual configuration.

Standard scopes request groups of claims: openid is mandatory, while profile, email, address and phone add attributes. Requesting only the scopes the application needs follows the principle of data minimization.

Clients fall into two classes. Confidential clients, such as server-side web applications, hold a client secret or a private key for authenticating at the token endpoint. Public clients, such as mobile apps and single-page applications, cannot keep a secret, so they depend entirely on PKCE and exact redirect URI registration. Companion specifications add RP-initiated, front-channel and back-channel logout, which let a sign-out at the provider end sessions in connected applications, although support for these logout methods varies considerably between providers.

OpenID Connect compared with OAuth 2.0 and SAML

OIDC, OAuth 2.0 and SAML are often mentioned together, but they solve different problems or the same problem in different eras. The comparison clarifies when each applies.

The key lesson is that an OAuth access token is not proof of identity. Using one to log users in, sometimes called pseudo-authentication, has caused real account takeover vulnerabilities; OIDC exists precisely to make the identity statement explicit and verifiable.

Security pitfalls in OIDC implementations

OpenID Connect is secure when implemented with mature libraries, but hand-written validation frequently skips checks. The most common flaws are listed below.

• Skipping signature or audience validation, which lets tokens issued for another application be accepted.
• Accepting the `none` algorithm or allowing the token header to choose the verification algorithm.
• Loose redirect URI matching, which allows authorization codes to be stolen through open redirects.
• Missing `state` and `nonce` checks, enabling cross-site request forgery and token replay.
• Storing tokens in browser local storage where cross-site scripting can read them; a back-end session is safer.
• Trusting unverified email claims to link accounts, which enables takeover across providers.

Token lifetimes matter as well. ID tokens are typically valid for minutes rather than hours, and applications should rely on their own sessions and refresh tokens instead of reusing an ID token as a long-lived credential.

In plain words

OpenID Connect is a trusted way for one service to vouch for who you are to another. When you click a button to sign in with your work account, the app sends you to your company’s login page. You prove who you are there, and the app receives a signed note saying who you are.

The app never sees your password. It only checks that the note is genuine, recent and addressed to it. This is how one login can open many applications safely.

A real-world example

A company of 900 employees introduces a new expense management application. Instead of creating separate passwords, the IT team registers the application as an OpenID Connect client at the corporate identity provider, configures the authorization code flow with PKCE, and limits scopes to openid, profile and email.

Employees now sign in through the familiar company login page with their passkey. The application validates each ID token, links accounts by the iss and sub pair and checks the amr claim to confirm multi-factor authentication. When an employee leaves, disabling one account at the provider removes access to the expense tool immediately, and the audit team gains a single place to review sign-in history.