Digital Privacy Base
D Digital Privacy

What is OpenID Connect (OIDC) & What You Need to Know in 2025

October 26, 2025

TL;DR

OpenID Connect (OIDC) is the identity layer built on top of OAuth 2.0. It lets applications (relying parties) verify who a user is via a trusted OpenID Provider (OP) like Google, Microsoft Entra ID (Azure AD), Apple, or Amazon Cognito—without handling passwords. OIDC uses JWT-based ID tokens, standard scopes, and endpoints like /authorize, /token, /userinfo, and well-known discovery to make authentication safe, interoperable, and developer-friendly. In 2025, the recommended default for web, mobile, and SPA apps is Authorization Code Flow with PKCE. Use OIDC for SSO, consumer social logins, and identity federation; use OAuth 2.0 alone only when you need authorization to resources without authenticating the user. Use SAML when integrating with legacy enterprise IdPs that still prefer XML assertions.

Authentication has changed quickly. Password‑only sign‑ins are giving way to standards‑based identity flows that are safer, faster, and easier to integrate.

OpenID Connect (OIDC) sits at the center of that shift. Built on OAuth 2.0, OpenID Connect gives your app a portable way to verify who a user is, request only the profile data you need, and respect consent across web, mobile, and device experiences.

This article demystifies the moving parts—OpenID Provider, Relying Party, tokens, scopes, and endpoints—and shows how they come together in real logins like “Continue with Google.”

Whether you’re shipping B2C social sign‑in or B2B tenant SSO, you’ll find actionable patterns, security checklists, and implementation steps you can apply immediately. We’ll also clarify when to choose OIDC over SAML and how to avoid common pitfalls that lead to account takeover.

What is OpenID Connect (OIDC)?

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. OAuth answers “What can this app do on the user’s behalf?” (authorization). OIDC answers “Who is this user?” (authentication). 

OpenID Connect (OIDC) connection map
Image Source: OpenID

OIDC standardizes how apps verify identity and obtain basic profile data via ID tokens and standard scopes, without sharing user passwords with the app.

  • Final specification date: February 26, 2014.
  • Maintained by: The OpenID Foundation, with contributions from companies like Google and Microsoft.
  • Where it shows up: The ubiquitous “Continue with Google/Apple/Microsoft” buttons, modern SSO implementations, B2C social logins, and B2B SaaS SSO.

Why not just OAuth 2.0?

Historically, OAuth 2.0 was created for delegated access—e.g., letting an app access your Google Calendar without revealing your Google password. OAuth doesn’t define identity; it’s possible to get an access token and still not know who the user is. So, it’s great for people maintaining a burner identity.

Before OIDC, each provider returned user info in different formats, causing painful, non‑portable integrations. OIDC fixes this by:

  • Defining a standard identity token (the ID token, usually a JWT) with well-known claims.
  • Standardizing scopes (e.g., openid, profile, email, phone, address).
  • Providing a UserInfo endpoint for richer profile data.
  • Specifying discovery and JSON Web Key Sets (JWKS) for automated config and key validation.

Where OIDC fits best

  • Modern apps (web, SPA, mobile) needing sign-in and SSO.
  • Consumer scenarios (social logins) with built-in consent.
  • B2B SSO where tenants connect their corporate IdP and you need granular control over who can access what.
  • Device and console/TV logins via device-code flows.

Core roles and terminology

  • End User (EU): The person trying to sign in (OAuth’s resource owner).
  • Relying Party (RP): Your app/website that relies on the provider to authenticate the user (OAuth’s client).
  • OpenID Provider (OP): The identity service that authenticates users, obtains consent, and issues tokens (often also the OAuth authorization server; may expose a resource server for userinfo).

OP examples: Google, Microsoft Entra ID (Azure AD), Apple ID, Amazon Cognito, and many commercial/OSS IdPs.

Supporting concepts you’ll use in production:

  • Discovery document: /.well-known/openid-configuration — a JSON document describing the OP’s endpoints, scopes, claims, and keys.
  • JWKS endpoint: A set of public keys the OP uses to sign tokens; RPs use it to validate token signatures.

Scopes & claims: Scopes request permission to access categories of data; claims are the pieces of data (e.g., email, name) contained in tokens or returned by userinfo.

Tokens in OIDC and how to handle them correctly

OIDC layers identity onto OAuth’s token model. You’ll typically encounter three tokens:

  1. ID Token (OIDC) — Who the user is and how/when they were authenticated. Usually a JWT and digitally signed. It may be encrypted, but signatures + TLS are typically sufficient. Do not treat the ID token as a bearer credential for APIs.
  2. Access Token (OAuth 2.0) — What the app can access. Used to call protected APIs (including userinfo). May be opaque or JWT, short‑lived.
  3. Refresh Token (OAuth 2.0) — Lets the app get new access tokens without re‑prompting the user. Handle carefully; use rotation with reattestation.

Required core ID token claims

While OPs can add many claims, the following are core, standardized fields you’ll see across providers:

  • iss — Issuer (the OP’s identifier)
  • sub — Subject (stable, unique user identifier at this OP)
  • aud — Audience (client/RP the ID token is intended for)
  • exp — Expiration time (Unix seconds)
  • iat — Issued-at time

Common, highly useful optional claims:

  • auth_time (time of user authentication), nonce (binds response to request; critical for SPAs), acr/amr (assurance/authentication methods), email, email_verified, name, picture.

Validating an ID token (server-side checklist)

  1. Parse the JWT and verify its signature against the OP’s JWKS.
  2. Check iss matches the provider you configured.
  3. Check aud contains your client ID.
  4. Ensure exp is in the future and iat not too far in the past (clock skew).
  5. If you sent a nonce, verify it matches the value in the ID token.
  6. Optionally ensure azp (authorized party) matches expectations in multi‑audience cases.
  7. Enforce clock skew tolerance and reject tokens failing checks.

Note: For SPAs and mobile apps, encryption of the ID token is generally not useful—attackers can discover client‑side keys. Lean on TLS, short lifetimes, and server‑side validation.

The UserInfo endpoint

OIDC provides a standardized HTTP API—the UserInfo endpoint—to fetch additional user attributes after authentication using the access token. This is especially useful because ID tokens are for authentication and often include only basic claims. UserInfo typically returns:

  • sub, name, preferred_username, email, email_verified, picture, and more—
  • Depending on scopes the RP requested and the user consented to (e.g., profile, email, phone, address).

Design note: The ID token is a static snapshot at authentication time. UserInfo lets you fetch current profile data, subject to authorization.

Scopes and consent in OIDC

Scopes communicate what you want; consent communicates what the user allows.

  • openid — Mandatory in OIDC requests; it flags that “this is an OIDC request.”
  • profile — Name, preferred username, profile picture, etc.
  • email — Email, email_verified.
  • phone — Phone number, phone_number_verified.
  • address — Postal address fields.

Principle of least privilege: Ask only for the scopes you need. Over‑requesting data leads to lower conversion and higher privacy risk. Build in revocation and transparent data usage.

How OIDC works (end-to-end)

The OIDC flow ties together the RP, the user, and the OP. Here’s a high‑level sequence that maps to what users see in the wild (e.g., “Continue with Google”):

  1. User hits “Sign in with ”.
  2. RP builds an authorization request and redirects the user-agent to the OP’s /authorize endpoint with parameters like client_id, redirect_uri, response_type, scope (must include openid), state (CSRF protection), and often nonce (replay protection).
  3. OP authenticates the user (password, passkey, OTP, biometrics, federation, etc.) and prompts for consent to share requested scopes. OIDC itself doesn’t dictate how the user logs in—the IdP chooses one or multiple factors (MFA encouraged).
  4. OP issues tokens according to the chosen flow—always an ID token for authentication, and often an access token (plus optionally a refresh token).
  5. RP validates the ID token (and exchanges codes where applicable), then creates a local session and optionally calls UserInfo for richer attributes.
  6. User is redirected back to the RP and logged in.

OIDC flows and choosing the right one

OIDC inherits OAuth’s grant types but repurposes them as authentication flows. Your choice depends on client type and security posture.

1) Authorization Code Flow (recommended)

  • What it is: The RP receives a short‑lived authorization code via front channel, then exchanges it for tokens using a back‑channel request to /token.
  • Why it’s best: Tokens aren’t exposed in the browser address bar; server can securely store/validate them.
  • Use for: Traditional web apps and public clients (SPAs, mobile) with PKCE.

Add PKCE (Proof Key for Code Exchange)

PKCE protects the code exchange from interception. The client generates a random code_verifier and sends a derived code_challenge (typically S256) in the initial request; later it must present the original code_verifier to exchange the code. The OP verifies these match—blocking attackers that intercepted the authorization code.

Always use PKCE for mobile and SPA—and increasingly for confidential web apps too.

2) Implicit Flow (legacy; avoid if possible)

  • What it is: Tokens are returned directly in the redirect URI (fragment).
  • Why it’s discouraged: Higher risk of token leakage via browser history, logs, or intermediaries.
  • Status: Kept for backward compatibility; prefer code + PKCE.

3) Hybrid Flow

  • What it is: A blend—some tokens (often ID token) return immediately; authorization code is also returned for server exchange.
  • When to use: Niche cases that require earlier identity hints while still securing access token exchange.

4) Device Authorization (Device Code) Flow

  • What it is: For devices lacking a browser/keyboard (TVs, consoles). The device shows a code and URL. The user confirms on another device; the app then receives the ID token and (optionally) access token.
  • Security: Works well when UI is constrained; still honor short lifetimes and rate limits.

5) Client Credentials Flow (not for user authentication)

  • What it is: Machine-to-machine authorization using a client’s own credentials to get an access token.

Use case: Server-to-server calls with no user present. Not an OIDC login.

Security model and best practices

OIDC is secure when implemented correctly. It benefits from OAuth’s proven design plus identity‑specific defenses. Here’s a pragmatic checklist your security reviewers will expect:

Protocol-level protections

  • PKCE: Mandatory for public clients (SPA, mobile). Strongly recommended everywhere.
  • state: Random, unguessable; prevents CSRF and misbinding.
  • nonce: For OIDC responses; mitigates replay and token substitution.
  • Exact redirect_uri matching**:** Register and enforce precise redirect URIs.
  • HTTPS everywhere: Never allow non‑TLS endpoints.
  • Scopes least privilege: Request only what you need; revisit scopes as your app evolves.
  • Short‑lived access tokens: Prefer minutes; rely on refresh token rotation with binding signals.
  • Token binding/DPoP (where available): Consider sender-constrained tokens to reduce bearer theft impact.

Token handling

  • ID token usage: Never call APIs with it; it’s not an access credential.
  • Audience enforcement: Check aud and, if provided, azp.
  • Key rotation: Periodically refresh the OP’s JWKS; cache with reasonable TTL. Handle key rollover gracefully.
  • Clock skew: Allow a small skew (e.g., ±3–5 minutes); reject obviously stale/future tokens.
  • Logout: Support RP‑initiated and, where applicable, front-channel/back-channel logout to propagate session termination.

Authentication strength & step-up

  • Use acr/amr claims to record assurance level and methods used (e.g., pwd, otp, fido2).
  • For sensitive actions, require step‑up: re-prompt with stronger factors or max_age constraints.

Known pitfalls & hardening

  • Implicit flow: Avoid for new builds.
  • Over-trusting access tokens from unknown issuers: Validate iss, aud, and token signature.
  • Mixing tenants: In B2B, isolate tenants via unique client IDs, redirect URIs, and audience per tenant where feasible.
  • Leaky logs: Don’t log tokens or PII from userinfo responses.
  • Excessive scopes: Leads to consent fatigue and privacy risk; minimize and explain why you need each scope.
  • Account linking: When supporting multiple IdPs, use careful linking flows to prevent account takeover via recycled emails or social identities.

Real-world note: In 2023, researchers disclosed an implementation flaw impacting some OAuth/OIDC apps using “Log in with Microsoft” that enabled account takeover in certain misconfigurations.

The lesson isn’t that OIDC is broken—it’s that misconfigurations (redirect URIs, validation, and token checks) are the usual culprits. Treat your implementation as security-critical and test accordingly.

How to Implement OIDC

1) Design your login strategy

  • Providers to support: Google, Microsoft, Apple, enterprise IdPs (via OIDC), plus username/password or passkeys if needed.
  • Flows: Default to Authorization Code + PKCE for web, SPA, and mobile. Use Device Code for TVs/consoles.
  • Data needs: Start with openid email profile; add phone/address only if required.
  • Session model: Server-side sessions with HttpOnly, SameSite cookies; map OP sessions to your app sessions.

2) Configure the OpenID Provider (OP)

  • Register your client (RP) and obtain client_id (and, for confidential clients, client_secret).
  • Register exact redirect_uri values; avoid wildcards.
  • Retrieve .well-known/openid-configuration and cache OP metadata and JWKS.

3) Build the authorization request

  • Endpoint: /authorize
  • Include: client_id, redirect_uri, response_type=code, scope=openid email profile, state=<random>, nonce=<random>, code_challenge, code_challenge_method=S256.

4) Exchange code for tokens

  • Endpoint: /token (back channel, server-to-server).
  • Include: grant_type=authorization_code, code, redirect_uri, client_id (+ client_secret if confidential), code_verifier.

5) Validate tokens & create session

  • Validate ID token signature & claims; enforce audience, issuer, expiration, and nonce.
  • Store only what you need (e.g., sub, email, email_verified).
  • Create a local session; optionally fetch UserInfo with the access token.

6) Handle refresh & logout

  • Use refresh token rotation where available.
  • Respect OP session timeouts and implement front-/back-channel logout if supported.
  • Provide user‑initiated disconnect to revoke consents.

7) Production hardening

  • Secrets in a vault; rotate regularly.
  • CSP, anti‑clickjacking headers; strict transport security.
  • Rate limit /callback and device polling.
  • Monitor login success/failure rates; alert on anomalies.

OIDC benefits

For users

  • Fewer passwords to juggle; faster login.
  • Consistent sign-in across devices (web, mobile, TV).
  • Transparent consent over shared data.

For developers & businesses

  • Stronger security baseline: No password handling; adopt MFA.
  • Interoperability: JSON, JWTs, standardized endpoints.
  • Lower drop-off: Familiar social and enterprise logins reduce friction.
  • Scalability: Offload auth to well-tested providers; focus engineering on your product.

Conclusion

OpenID Connect (OIDC) is the modern standard for authenticating users across web, mobile, API-first, and device experiences. By building on OAuth 2.0 and adding a robust identity layer—ID tokens, standardized scopes, UserInfo, and discovery—OIDC makes authentication interoperable, secure, and scalable.

Choose Authorization Code with PKCE as your default, keep scopes lean, validate tokens rigorously, and design for consent, privacy, and clear UX. For B2B SSO and consumer social logins alike, OIDC remains the most future‑proof path.

Leave a Reply

Your email address will not be published. Required fields are marked *