The Most Common Confusion in Auth
Ask a developer "what's the difference between OAuth 2.0 and OpenID Connect?" and you'll often get a shrug or a half-answer. This confusion is understandable — the two technologies are deeply intertwined and frequently mentioned together. But they solve different problems, and mixing them up leads to insecure implementations.
The short version: OAuth 2.0 is an authorization framework. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. Let's unpack what that actually means.
OAuth 2.0: Delegated Authorization
OAuth 2.0 (defined in RFC 6749) is a framework for delegated authorization. It allows a user to grant a third-party application limited access to their resources on another service — without giving that application their password.
The classic example: you authorize a calendar app to read your Google Calendar. The app gets an access token that lets it call the Google Calendar API on your behalf. OAuth 2.0 defines how that token is requested, issued, and used.
Crucially, OAuth 2.0 does not define who the user is. The access token proves the app is authorized to do something — it says nothing about the user's identity. This is the gap that OpenID Connect fills.
OpenID Connect: Authentication on Top of OAuth 2.0
OpenID Connect (OIDC) extends OAuth 2.0 by adding a standardized way to authenticate users and obtain their identity information. It introduces:
- ID Token — A signed JWT (JSON Web Token) that contains claims about the authenticated user (subject ID, email, name, etc.) and when/how authentication happened.
- UserInfo Endpoint — An OAuth-protected endpoint the client can call with an access token to fetch additional user claims.
- Discovery Document — Published at
/.well-known/openid-configuration, this JSON document describes the provider's endpoints and supported features. - Standard Scopes — OIDC defines scopes like
openid,profile,email, andaddressto request specific identity data.
Side-by-Side Comparison
| Aspect | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Primary purpose | Authorization (access control) | Authentication (identity verification) |
| Key artifact | Access Token | ID Token (JWT) + Access Token |
| Answers the question | "Can this app do X?" | "Who is this user?" |
| User info | Not standardized | Standardized via ID Token & UserInfo |
| Discovery | Not defined | /.well-known/openid-configuration |
| Built on | Nothing (it's foundational) | OAuth 2.0 |
Common Flows You'll Encounter
Authorization Code Flow
The most secure and widely recommended flow. The user is redirected to the authorization server, authenticates, and the server returns an authorization code to your application. Your server exchanges this code for tokens. Works for both OAuth 2.0 and OIDC (when the openid scope is included).
PKCE (Proof Key for Code Exchange)
An extension to the Authorization Code Flow designed for public clients (SPAs, mobile apps) that cannot securely store a client secret. PKCE should be used for any public client — it's now considered standard practice.
When to Use What
- Use OAuth 2.0 alone when you need to grant API access to a third party and don't need to know who the user is (e.g., machine-to-machine API access using Client Credentials flow).
- Use OpenID Connect whenever you need to log a user in, establish their identity, or implement Single Sign-On (SSO). OIDC is the right choice for "Login with Google/GitHub/etc." integrations.
- Never use an OAuth access token as proof of identity — this is a common and dangerous mistake. Always use OIDC's ID Token for authentication.
Key Takeaway
Think of it this way: OAuth 2.0 is a lock with a key. OpenID Connect also tells you who made the key. Both are essential tools in modern auth systems, and understanding the boundary between them is fundamental to building secure applications.