OpenID Connect identity is the layer of sign-in information that the OpenID Connect standard adds on top of OAuth 2.0, letting an application learn reliably who a user is and how they signed in. It powers many of the continue-with buttons on consumer sites and many modern workplace sign-ins.
This guide explains the identity side of OpenID Connect, often shortened to OIDC: the ID token, the claims inside it, the recommended sign-in flow and the supporting pieces such as discovery and the UserInfo endpoint. It is written for developers new to identity and for technically curious users who want to understand what a sign-in button really does.
A Sign-In Standard Built on an Authorization Framework
OAuth 2.0 was designed for delegated authorization: letting an application access resources on your behalf, such as reading your calendar, without learning your password. It issues access tokens that say what an application may do, but it does not define a standard way to say who the user is.
Early on, many sites stretched OAuth into a login system anyway, each in its own way. Those ad hoc approaches produced inconsistent and sometimes unsafe results, because an access token proves permission, not identity. A token meant for one application could be misused to sign in to another.
OpenID Connect fixed this by standardizing the missing identity piece. It reuses OAuth 2.0’s redirects, endpoints and token exchange, then adds an ID token designed specifically to describe an authentication event. The result is a sign-in protocol that developers can implement consistently across many identity providers.
The Three Roles in an OpenID Connect Sign-In
OpenID Connect uses its own vocabulary for the familiar federation roles. The end user is the person signing in. The OpenID Provider, or OP, is the identity provider that authenticates the user and issues tokens. The relying party is the application that wants to know who the user is.
In OAuth terms, the relying party is also a client, because it requests tokens from the provider’s authorization server. Clients come in two broad kinds. Confidential clients, such as server-side web applications, can keep a secret safe. Public clients, such as mobile apps and single-page browser apps, cannot reliably hide secrets from determined users.
That distinction shapes how each client proves its identity to the provider and which protections it must use. A server-side application can authenticate with a client secret or a signed key, while a mobile app relies on additional techniques, explained below, to stop intercepted authorization codes from being redeemed by an attacker.
Inside the ID Token
The ID token is the heart of OpenID Connect identity. It is a JSON Web Token, or JWT, a compact text format containing a set of statements called claims, protected by the provider’s digital signature. Relying parties verify that signature before trusting any claim inside.
- Issuer (iss): identifies the provider that created the token.
- Subject (sub): a stable, unique identifier for the user at that provider.
- Audience (aud): the client ID of the application the token was issued for.
- Issued and expiry times (iat, exp): when the token was created and when it stops being valid.
- Nonce: a random value from the original request that ties the token to that request.
- Authentication details (auth_time, acr, amr): when and how the user signed in.
The combination of issuer and subject is the correct way to identify a user across sessions. Email addresses may also appear as claims, but they can change and are not always verified, so they should not serve as the primary account key.
How the Authorization Code Flow Works
OpenID Connect defines several flows, meaning sequences of requests between browser, application and provider. Current security guidance recommends the authorization code flow for nearly all applications, combined with an extension called PKCE. Older flows that returned tokens directly in the browser address are discouraged.
Step One: The Authentication Request
The application redirects the browser to the provider’s authorization endpoint with its client ID, a registered redirect address, the openid scope and random state and nonce values. The provider authenticates the user, may show a consent screen, then redirects back with a short-lived authorization code rather than the tokens themselves.
Step Two: The Code Exchange
The application sends the authorization code to the provider’s token endpoint over a direct, encrypted connection, along with its client credentials if it is confidential. The provider returns an ID token, an access token and sometimes a refresh token. Keeping tokens out of the browser address bar reduces leakage through logs and history.
Proof Key for Code Exchange
PKCE, pronounced pixie, protects the exchange. The application creates a random secret, sends a hashed version with the first request and reveals the original only during the code exchange. A stolen authorization code is useless without that secret, which matters most for mobile and browser apps that cannot hold a client secret.
Scopes and Claims: Asking for Profile Details
Scopes are labels an application includes in its request to say what it wants. The openid scope is mandatory and signals an OpenID Connect sign-in. Standard optional scopes such as profile, email, address and phone ask the provider to release groups of related claims.
Each scope widens what the provider shares, and consent screens usually list them for the user. Requesting only openid and email, for example, yields a stable identifier and an address for notifications without exposing birth date or location. Providers may also support custom scopes and claims for organization-specific information like roles.
A sensible rule is to request the smallest set that lets the application function, then ask for more later if a feature genuinely needs it. Users are more willing to approve narrow requests, and the application stores less personal data that it must protect and eventually delete under laws such as GDPR.
Discovery Documents and Published Signing Keys
OpenID Connect providers publish a discovery document, a machine-readable file at a well-known address under the provider’s domain. It lists the provider’s issuer identifier, endpoint addresses, supported scopes and signing algorithms, and the location of its public keys.
The public keys are published as a JSON Web Key Set, often called the JWKS. Relying parties fetch these keys to verify ID token signatures. Because the keys are retrieved from the provider’s own domain over an encrypted connection, the provider can rotate keys without contacting every client individually.
Discovery reduces configuration errors, but it does not remove the need for care. Applications should pin the expected issuer value, cache keys sensibly and refresh them when a token arrives signed with an unfamiliar key identifier. They should never accept a token whose signature algorithm is set to none, a weakness some older libraries tolerated.
Libraries handle most of this automatically, but confirm the configuration rather than assuming defaults are safe, especially after upgrading a library or switching providers.
The UserInfo Endpoint and Its Proper Role
Besides the ID token, OpenID Connect defines a UserInfo endpoint. An application presents its access token to this endpoint and receives claims about the user, such as name, email or profile picture, according to the scopes the user approved.
The ID token and UserInfo serve different purposes. The ID token is a signed record of an authentication event, intended for the application that requested it. UserInfo is a convenient way to fetch profile details, sometimes more than fit comfortably in a token, and to retrieve updated values later.
When using UserInfo, check that the subject it returns matches the subject in the ID token. A mismatch indicates a mix-up between users or tokens and should stop the sign-in. Treat UserInfo data as profile information rather than proof of authentication, because the authentication proof lives in the validated ID token.
Sessions and Logout in OpenID Connect
After a successful sign-in, the relying party creates its own session, and the provider maintains a separate one. OpenID Connect includes optional specifications for coordinating these, such as notifying applications when a user signs out at the provider. Support varies, so check what your provider and libraries implement.
Applications can also request fresh authentication. A request can ask the provider to prompt the user again or to require a recent sign-in, and the auth_time claim lets the application confirm how long ago authentication actually happened. This supports reauthentication before sensitive actions such as changing payment details.
Refresh tokens deserve careful handling. They let an application obtain new access tokens without user involvement, sometimes for long periods. Store them securely on the server, use rotation where the provider supports it and revoke them when a user signs out, changes their password or removes the application’s access.
Implementation Mistakes That Weaken OIDC
OpenID Connect is a well-reviewed standard, but implementations can still go wrong. Most weaknesses come from skipping checks or choosing outdated flows rather than from flaws in the protocol. Using a maintained, certified library avoids many of them.
- Using an access token as proof of sign-in instead of validating the ID token.
- Skipping checks on the issuer, audience, expiry or nonce in the ID token.
- Omitting the state parameter, which protects the redirect against cross-site request forgery.
- Choosing implicit or hybrid flows for new apps instead of the code flow with PKCE.
- Registering broad wildcard redirect addresses that let tokens reach attacker-controlled pages.
Cross-site request forgery, mentioned above, is an attack in which a malicious page silently triggers a request in the user’s browser. The state value lets the application confirm that a returning response belongs to a request it actually started.
What OpenID Connect Means for Everyday Users
For people signing in, OpenID Connect usually appears as a button offering to continue with an existing account, followed by a consent screen. That screen lists the scopes the application requested, which tells you exactly what profile details it wants.
Read it before approving. An app that only needs to recognize you should not ask for contacts or phone numbers. If the request seems excessive, cancel and use a different sign-in method. You can later review and remove connected applications in your identity provider’s account settings, which stops future sign-ins and data sharing.
Remember that the security of every connected app depends on your provider account. Protect it with a unique passphrase and a phishing-resistant method such as a passkey. OpenID Connect itself keeps your password away from the application, but it cannot protect an account whose credentials an attacker has already captured.
Adopting OpenID Connect Safely in New Projects
For a new application, start with a maintained OpenID Connect library rather than writing token handling from scratch. Configure the authorization code flow with PKCE, exact redirect addresses and the smallest set of scopes. Load provider settings from the discovery document and confirm the expected issuer explicitly.
Write tests that feed the application expired, tampered and misaddressed ID tokens and confirm each one is rejected. Key accounts on issuer plus subject, store refresh tokens on the server and plan for reauthentication before sensitive actions. Log sign-in outcomes without recording raw tokens.
Revisit the setup whenever your provider changes keys, algorithms or recommended flows. Standards bodies and providers update guidance as new attacks are understood, so subscribe to your provider’s security notices. A modest review routine keeps OpenID Connect identity doing what it was designed for: telling your application who signed in, reliably and with minimal data.