The short version: OAuth 2.0 is an authorization protocol. OpenID Connect is an authentication layer built on top of it.
That distinction sounds academic until it produces a security bug, which it regularly does. The most common one — using an OAuth2 access token to decide who the user is — is worth understanding properly.
What OAuth 2.0 actually does
OAuth 2.0 solves delegated authorization: letting an application act on a user's behalf against some API, without the user handing over their password.
The output is an access token. It answers one question:
Is the bearer of this token allowed to do X?
Notice what it doesn't answer: who the bearer is. An access token is a capability. It says what may be done, not who is doing it. The spec deliberately says nothing about the token's format — it can be an opaque random string, and frequently is.
What OpenID Connect adds
OIDC is a thin layer on top of OAuth 2.0 that adds identity. Concretely, three things:
1. The ID token. A JWT, always, with a defined claim set — iss, sub,
aud, exp, iat. It answers "who is this user, and which issuer is
asserting that?" This is the piece OAuth2 has no equivalent for.
2. The openid scope. Requesting it is what turns an OAuth2 authorization
request into an OIDC one. No openid scope, no ID token.
3. Standardized discovery and userinfo. A document at
/.well-known/openid-configuration describing every endpoint, and a /userinfo
endpoint returning claims about the authenticated user. OAuth2 standardizes
neither, which is why pre-OIDC integrations were bespoke per provider.
The distinction that causes bugs
Here's the failure mode. An app receives an access token, decodes it, finds a
sub claim, and treats that as the logged-in user.
This breaks for two reasons.
Access tokens aren't for you. An access token's audience is the API, not your client. You're not the intended recipient, and you have no guarantee about its format or contents. Many providers issue JWTs and it happens to work — until the provider changes its token format, which it's entitled to do without warning, because the contents were never part of your contract.
Anyone can present a token. Access tokens are bearer tokens. If your app accepts one as proof of identity, then a malicious app that obtained a token for a different client can hand it to you, and you'll accept it as evidence that the user is signed in. This is the confused deputy problem, and it's why the OAuth2 spec explicitly warns against using access tokens for authentication.
ID tokens exist precisely to close this. They carry an aud claim naming your
client ID, and you are required to validate it. A token minted for another client
fails that check.
Practical rules
- Identifying the user in your app? Use the ID token. Validate
iss,aud,exp, and the signature — all four. - Calling an API? Send the access token. Don't inspect it; it isn't yours to interpret. The API validates it.
- Need fresher or richer profile data than the ID token carries? Call
/userinfowith the access token. - Never make an authorization decision from an unvalidated JWT, of either kind.
A useful mental model
Airport security. Your boarding pass is the access token: it grants passage through a specific gate, and the agent checking it cares only that it's valid for that flight. Your passport is the ID token: it asserts who you are, issued by an authority, and it's checked against you specifically.
You can't board with a passport, and you can't prove your identity with a boarding pass — even though both were issued to you on the same trip.
Checking what your provider issues
The fastest way to see the difference is to look at real tokens. Run an
authorization request with our
OAuth Flow Tester, then paste the ID token and
the access token into the JWT Decoder side by side.
The aud claims will differ — that's the whole story in one field.
To inspect any provider's supported scopes, response types, and endpoints, the
OIDC Discovery tool fetches and formats its
.well-known/openid-configuration.
AuthAction implements both protocols; the endpoint reference covers which endpoint returns which token.