OpenID Connect (OIDC)

OpenID Connect (OIDC) is the authentication protocol behind most modern web and mobile sign-in, built on top of OAuth 2.0 and its successor OAuth 2.1. OAuth lets an application obtain access to an API but never tells it who the user is; OIDC adds that answer, so an application can hand login to an identity provider and receive a signed statement of who authenticated and when, which is what makes single sign-on across many applications work. That statement is the ID Token, a signed JSON Web Token (JWT) carrying identity claims such as sub (user ID), iss (issuer), aud (audience), and optional profile information (email, name); further attributes come from the userinfo endpoint using scopes like openid (mandatory), profile, and email.

Which Flow for Which Client

OpenID Connect Core defines three ways to obtain an ID Token, and a new deployment needs only one of them. In the authorization code flow the application sends the browser to the OpenID provider, which authenticates the user and returns a short-lived code to the application's redirect URI. The application redeems the code in a direct call to the token endpoint and receives the ID Token there, never through the browser. With Proof Key for Code Exchange (PKCE), which OAuth 2.1 requires, this one flow covers server-side web applications, mobile and desktop apps that open the system browser instead of an embedded web view, and single-page applications, ideally behind a backend-for-frontend that holds the tokens.

The implicit flow returned the ID Token in the redirect URL itself, and the hybrid flow returns some tokens that way and others from the token endpoint. Both date from a time when browsers could not make cross-origin calls, and both put tokens where browser history, server logs and referrer headers can read them. A migration inventory treats a client still registered for either the same way it treats a client on the OAuth implicit grant.

Where there is no browser, OpenID Connect rides on OAuth extensions: the device authorization grant for televisions and command-line tools, and Client-Initiated Backchannel Authentication (CIBA), in which the application starts authentication server-to-server and the user approves on a separate registered device. A service with no user behind it does not need OpenID Connect at all. It authenticates with the client credentials grant or a workload identity.

An application finds the provider's endpoints and signing keys in its discovery document at /.well-known/openid-configuration and should refresh the keys from there, not pin them, because providers rotate signing keys. Discovery locates a provider but says nothing about whether it should be trusted. Inside one organization configuration settles that; across many organizations, as in research, education and government federations, OpenID Federation adds signed statements resolved to a trust anchor.

What the ID Token Says, and What It Does Not

The ID Token is a statement from the provider to one application: this user, identified by sub at issuer iss, authenticated at auth_time, with the methods listed in amr, at the assurance level named in acr. The aud claim names the client it was issued to, and nonce ties it to the login request that client started. An application validates the signature against the keys from the provider's JSON Web Key Set (JWKS) endpoint and then checks iss, aud, exp and nonce. Skipping any one of these checks lets a token issued to another application, or replayed from an earlier login, sign someone in.

Three mistakes recur in production, and each reads more into the token than it says. The first is sending it to an API as if it were an access token. An ID Token is addressed to the client, so an API that accepts one accepts a token that was issued to someone else; APIs take access tokens, whose audience is the API. The second is keying accounts on email. The stable identifier of a user is the pair of iss and sub, whereas an email address can change, can pass to another person when it is recycled, and at a multi-tenant provider can be set by a tenant's own administrators, which has led to account takeover when applications matched on it. Linking a federated login to an existing account by email is safe only when the provider asserts email_verified and the application trusts that provider's verification. The third is using the ID Token for authorization. Group and role claims are convenient, but they are a snapshot taken at login, and they stay in the application's session for as long as the session lasts, however soon the entitlement is withdrawn. What the user may do belongs to the application or to a policy decision point, whose interface OpenID AuthZEN standardizes.

Applications often ignore the authentication claims. An application that needs a stronger login for one transaction asks for it with acr_values, or forces a fresh login with max_age, and then has to check acr and auth_time in the token it receives, because a provider may complete the login at a lower level than was requested. Only that check makes a phishing-resistant login at the provider count at the application. Step Up Authentication Challenge carries the same request from an API that rejects a token because the login behind it was too weak.

Sessions and Logout

Signing in creates at least two sessions: one at the provider, and one at every application the user reaches from it, usually a cookie the application sets itself. Logging out has to end all of them. OpenID Connect has four final specifications for this, and they differ in how the provider reaches each application:

• RP-Initiated Logout lets the application send the browser to the provider's end-session endpoint with an id_token_hint, so that the provider session ends as well. Without it, a user who logs out of one application is still logged in at the provider, and the next click on "sign in" logs them straight back in.
• Front-Channel Logout has the provider load each application's logout URL in a hidden iframe, and Session Management has each application poll an iframe served by the provider. Both need the browser to send cookies inside a third-party frame, which browsers increasingly block, and both then fail without an error anyone sees.
• Back-Channel Logout has the provider post a signed Logout Token directly to each application's server, naming the user and the session by sid. It does not depend on the browser and works after the user has closed the tab. It asks more of the application: an endpoint the provider can reach, and a session store it can search by sid.

For a new deployment that means RP-initiated logout for the user's own click and back-channel logout for everything else, with front-channel logout kept only for applications that cannot accept a server-to-server call. Two limits remain. Logout ends sessions, and tokens outlive them: an access token already issued stays valid until it expires, and a refresh token until the provider revokes it, so a logout that is meant to cut off API access has to revoke refresh tokens as well. The Logout Token also reaches only applications registered with the provider. When the session to end lives in another domain, or the reason is a compromised account and not a user's click, the Shared Signals Framework carries session-revoked events between providers and applications, and Device Bound Session Credentials stops an application's session cookie from being replayed on another device. How long the provider session should last in the first place is a policy decision for single sign-on.

Profiles for High Assurance

OpenID Connect leaves many choices open: which flow, how a client authenticates, whether tokens are bearer or bound, whether a request travels in the URL or signed. Profiles close them for sectors where a wrong choice is expensive. The FAPI 2.0 Security Profile, final since February 2025 and written for open banking and other regulated APIs, allows only confidential clients and the authorization code flow. It requires Pushed Authorization Requests (PAR), so that the authorization request travels server-to-server instead of through the browser, and PKCE on every request. Clients authenticate with mutual TLS or private_key_jwt, access tokens are sender-constrained with mutual TLS or Demonstrating Proof of Possession (DPoP), and ID Tokens come only from the token endpoint. FAPI 2.0 Message Signing, final since September 2025, adds signed requests and responses where a transaction needs non-repudiation.

The International Government Assurance Profile (iGov) for OpenID Connect does the same for public services and is still an Implementer's Draft. It requires private_key_jwt client authentication, signed request objects, provider support for pairwise subject identifiers so that two services cannot correlate a citizen by sub, an assurance level in every ID Token as acr or as Vectors of Trust, and it recommends ID Token lifetimes of no more than five minutes.

An organization outside both sectors can still use the profiles as a hardening checklist for its own provider and clients. For procurement, OpenID Foundation certification against FAPI 2.0 says more than "supports OpenID Connect", because its conformance tests exercise the options that attacks exploit.

From Federated Login to Wallets

In OpenID Connect the provider takes part in every login. It authenticates the user and learns which application they are signing in to, every time. That is what lets it enforce policy and end sessions centrally, and it is also why the provider has to be available for every login and holds a record of the user's activity across applications. Verifiable Credentials change that relationship: the issuer signs a credential once, the user keeps it in a wallet, and a verifier checks it without contacting the issuer.

The OpenID Foundation built the protocols for this on OpenID Connect's own foundations, and both core specifications are final. OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 makes the wallet an OAuth client of the issuer, so an organization that runs an OpenID provider becomes an issuer by adding a credential endpoint to it. OpenID for Verifiable Presentations (OID4VP) 1.0 lets a relying party request credentials from a wallet with a request shaped like an authorization request, sent by redirect or, in the browser, through the W3C Digital Credentials API.

For a relying party the two are complements. OpenID Connect remains how it signs in users it holds accounts for. OID4VP is how it accepts attributes its own provider cannot vouch for, such as a government-issued identity at onboarding or proof of age, and there it can replace parts of identity proofing. The revised EU regulation on electronic identification and trust services (eIDAS) obliges many regulated services in the EU to accept the European Digital Identity Wallet, which makes running both side by side a near-term requirement for them. Self-Issued OpenID Provider v2 (SIOPv2), in which the wallet signs ID Tokens itself, is still an Implementer's Draft, and wallet ecosystems sign users in with OID4VP instead.

Choosing a Configuration

The protocol itself is settled, so the decisions an organization makes are about configuration. New applications use the authorization code flow with PKCE and key accounts on iss and sub. Logout is designed at the start, with back-channel logout wherever an application can accept it, because an application that never recorded sid has to rebuild its session handling before it can honor a Logout Token. Applications that handle payments, health data or administrative access take FAPI 2.0 as their baseline. SAML 2.0 assigns the same roles under other names, so the applications still on it are a migration to plan, not a second architecture to maintain. GNAP (RFC 9635) combines delegated authorization and identity information in one protocol and binds every request to a key the client holds, but it is not wire-compatible with OpenID Connect and has far less deployment, so it does not change these choices today.