The Confusion at the Heart of Modern Auth
Developers frequently conflate OAuth 2.0 and OpenID Connect (OIDC), and it's an understandable mistake — OIDC is built directly on top of OAuth 2.0 and the two are often deployed together. But confusing them leads to real security problems: using OAuth tokens for authentication when they were designed for authorization, or implementing OIDC flows that expose unnecessary data.
OAuth 2.0: Authorization, Not Identity
OAuth 2.0 is an authorization framework. Its purpose is to allow a third-party application to access resources on behalf of a user, without the user sharing their credentials with that application.
The core concepts are:
- Resource Owner: The user who owns the data.
- Client: The application requesting access.
- Authorization Server: Issues access tokens after authenticating the user and getting their consent.
- Resource Server: Hosts the protected resources and validates access tokens.
OAuth 2.0 produces an access token — a credential that says "this client is allowed to do X." Crucially, an access token says nothing about who the user is. It is not an identity assertion.
Using an access token to determine user identity is a common anti-pattern. Calling the authorization server's user endpoint with an access token can work in practice, but it is not standardized and varies between providers. That's exactly the gap OIDC fills.
OpenID Connect: Identity on Top of OAuth 2.0
OpenID Connect is an identity layer built on top of the OAuth 2.0 authorization framework. It adds a standardized way to authenticate users and obtain verified identity information.
OIDC introduces two key additions:
- ID Token: A signed JWT (JSON Web Token) that contains claims about the authenticated user — their subject identifier, the issuer, when they authenticated, and more. This is the identity assertion OAuth was missing.
- UserInfo Endpoint: A standardized endpoint where clients can retrieve additional profile claims using the access token.
OIDC also defines standard scopes (openid, profile, email, address, phone) so clients know exactly what information they're requesting — no more guessing provider-specific scope names.
Side-by-Side Comparison
| Aspect | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Primary purpose | Authorization (access control) | Authentication (identity verification) |
| Token issued | Access token | ID token + access token |
| Token format | Opaque or JWT (provider choice) | ID token is always a signed JWT |
| User identity | Not standardized | Standardized via ID token claims |
| Discovery endpoint | Not defined | Defined (/.well-known/openid-configuration) |
| Standard scopes | Not defined | openid, profile, email, etc. |
Which Flows Should You Use?
Both OAuth 2.0 and OIDC support several grant types (flows). For modern web and mobile applications:
- Authorization Code + PKCE: The recommended flow for both SPAs and native apps. PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks.
- Client Credentials: For machine-to-machine communication where no user is involved. OAuth 2.0 only — no OIDC needed since there's no human identity.
- Implicit Flow: Deprecated. Avoid in all new implementations.
Practical Decision Guide
- If you need to know who the user is (login), use OpenID Connect.
- If you need to access a user's data on a third-party service (e.g., Google Drive), use OAuth 2.0.
- Most login scenarios use both — OIDC for identity, OAuth for subsequent API access.
- Always validate the ID token: check the signature, issuer (
iss), audience (aud), and expiry (exp). - Never use an access token as proof of identity.
Understanding this distinction keeps your authentication architecture honest and prevents subtle but serious security vulnerabilities in how you identify and trust your users.