The Most Common Confusion in Auth
Developers new to authentication standards often use "OAuth" and "OpenID Connect" interchangeably. They're related — OpenID Connect (OIDC) is built on top of OAuth 2.0 — but they solve fundamentally different problems. Getting this distinction wrong leads to security issues and unnecessary implementation complexity.
OAuth 2.0: Authorization, Not Authentication
OAuth 2.0 is an authorization framework. It answers the question: "Can this application access this resource on behalf of this user?" It does not tell you who the user is — it only tells you what they've allowed your app to do.
When you use "Sign in with Google" implemented naively with plain OAuth 2.0, you get an access token. That token lets you call Google's APIs, but the OAuth spec itself doesn't define how to get the user's name, email, or a stable user ID. Developers historically hacked around this by calling a userinfo endpoint — but that was convention, not specification.
Core OAuth 2.0 concepts:
- Access Token: A credential granting access to specific resources/scopes.
- Refresh Token: A longer-lived token used to obtain new access tokens.
- Scopes: Strings defining what access the token grants (e.g.,
read:email). - Grant Types: Flows for obtaining tokens — Authorization Code, Client Credentials, Device Code, etc.
OpenID Connect: Identity on Top of OAuth 2.0
OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0. It answers: "Who is this user, and can I verify their identity?" OIDC adds a standardized way to get and verify identity information.
The key addition OIDC makes is the ID Token — a JSON Web Token (JWT) containing verified claims about the user, signed by the identity provider. Standard claims include:
sub— Subject identifier: a stable, unique user ID from the provideriss— Issuer: the identity provider's URLaud— Audience: your application's client IDexp/iat— Expiry and issued-at timestampsemail,name,picture— Optional profile claims
Because the ID Token is a signed JWT, your application can verify its authenticity without making an additional network request to the identity provider.
Side-by-Side Comparison
| Aspect | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Purpose | Authorization (delegated access) | Authentication (identity verification) |
| Primary output | Access Token | ID Token (JWT) + Access Token |
| Tells you who the user is? | No (by spec) | Yes |
| Standardized user info? | No | Yes (via ID Token claims) |
| Discovery mechanism | None built-in | OIDC Discovery (/.well-known/openid-configuration) |
| Token format | Opaque or JWT (varies) | JWT (required for ID Token) |
OIDC Discovery: Self-Describing Identity Providers
One underappreciated feature of OIDC is its Discovery document, served at /.well-known/openid-configuration. This JSON document describes the identity provider's supported endpoints, scopes, signing algorithms, and more — allowing client libraries to auto-configure themselves. This is what makes OIDC-compliant libraries so portable across different providers.
When to Use Which
- Use OAuth 2.0 alone when you need delegated API access without caring about user identity (e.g., a server-to-server integration, or accessing a user's Google Calendar data from a backend service).
- Use OpenID Connect when you need to authenticate users — i.e., you need to know who is logging in and maintain a user session in your application. OIDC is the right choice for SSO and user login flows.
- Use both together when you need login (OIDC) and also need to call APIs on behalf of the logged-in user (OAuth 2.0 access tokens).
Modern identity providers like Auth0, Okta, Keycloak, and Google Identity implement both, making it straightforward to handle both needs in a single flow.