OAuth vs OIDC.
OAuth 2.1 is an authorization framework — it issues scoped access tokens that let a client call an API on a user's behalf. OpenID Connect (OIDC) is a thin authentication layer built on top of OAuth that adds an ID token proving who the user is. OAuth answers "what may this client access?"; OIDC answers "who logged in?" Most modern apps use both together.
OAuth 2.1 vs OpenID Connect (OIDC).
| Dimension | OAuth 2.1 | OpenID Connect (OIDC) |
|---|---|---|
| Solves | Authorization (delegated access) | Authentication (who is the user) |
| Core artifact | Access token | ID token (a JWT) |
| Audience | Resource server / API | The client application |
| Built on | Standalone framework | A layer on top of OAuth 2.0 |
| Tells you | What the client may do | Who the user is + when/how they authenticated |
How they fit together
OAuth was designed for delegated authorization: letting an application access a resource on a user's behalf without handling the user's password. But OAuth deliberately says nothing about who the user is — it only governs access. Developers kept (incorrectly) using OAuth access tokens as a proxy for login, which was insecure.
OIDC standardized authentication on top of OAuth. A single authorization-code + PKCE flow can return both an ID token (OIDC — proves the user's identity to the app) and an access token (OAuth — lets the app call APIs). That is why nearly every "Sign in with…" button you use is OIDC riding on OAuth.
The 2026 baseline
For new builds, OIDC + OAuth 2.1 is the default: PKCE for all clients, no implicit flow, sender-constrained access tokens (DPoP or mTLS), and exact-match redirect URIs. Use OIDC for login, OAuth scopes for API authorization, and keep the two token types in their lanes — authenticate with the ID token, authorize with the access token.
When to use each.
Use OAuth (alone) when…
- A client needs delegated, scoped access to an API.
- There is no human login to model (machine-to-machine, client credentials).
Use OIDC when…
- You need to authenticate a user (login / SSO).
- You want a standardized ID token + userinfo, not a homegrown login.
Common questions.
Is OIDC a replacement for OAuth?+
No — OIDC is built on top of OAuth, not a replacement. OAuth handles authorization (access tokens); OIDC adds authentication (ID tokens) on top. You typically run both in the same flow.
Can I use OAuth for login?+
You should not use plain OAuth for authentication. OAuth access tokens prove what a client may access, not who the user is. Use OpenID Connect, which standardizes the ID token and userinfo endpoint for authentication.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.