The Confusion Is Understandable
OAuth 2.0 and OpenID Connect (OIDC) are often mentioned in the same breath, used in the same codebases, and sometimes conflated entirely. This confusion isn't just academic — misunderstanding the boundary between them leads to real security vulnerabilities and poorly designed systems.
Here's the clearest way to state it: OAuth 2.0 is an authorization framework. OpenID Connect is an authentication protocol built on top of it.
What OAuth 2.0 Actually Does
OAuth 2.0 solves a specific problem: how can a user grant a third-party application access to their resources on another service, without giving that app their password?
For example: how can a calendar app read your Google Calendar events without you giving it your Google password? The answer is OAuth 2.0 — the user grants the calendar app an access token with a limited scope, and the app uses that token to call Google's API.
OAuth 2.0 tells you nothing about who the user is. It only tells the resource server that the bearer of the token is authorized to perform certain actions. Authentication is deliberately out of scope.
What OpenID Connect Adds
OIDC extends OAuth 2.0 by adding a standardized identity layer. It specifies:
- A new token type: the ID Token (a signed JWT containing identity claims)
- A standard
/userinfoendpoint for fetching profile data - A discovery mechanism via
/.well-known/openid-configuration - Standard claims like
sub(subject/user ID),email,name,iat,exp - A
nonceparameter to prevent replay attacks
When you add scope=openid to an OAuth 2.0 request, you're asking for OIDC — you get back not just an access token, but also an ID Token that tells you who authenticated.
Side-by-Side Comparison
| Aspect | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Primary Purpose | Authorization (access delegation) | Authentication (identity verification) |
| Key Token | Access Token | ID Token (JWT) |
| Tells you… | What the app can do | Who the user is |
| Built on | RFC 6749 (base spec) | OAuth 2.0 |
| Discovery | None standardized | /.well-known/openid-configuration |
| User Profile Data | Not defined | /userinfo endpoint |
| Use for Login? | Not designed for this | Yes — purpose-built |
The "Log in with Google" Example
When you click "Log in with Google", both protocols are at work:
- Your app initiates an OIDC flow (OAuth 2.0 +
openidscope). - Google authenticates the user and issues an ID Token (OIDC) and an Access Token (OAuth 2.0).
- Your app uses the ID Token to confirm the user's identity and establish a session.
- If your app also needs to read Gmail, it uses the Access Token with the appropriate Google API scope.
Both protocols are present, serving distinct roles.
Common Mistakes to Avoid
- Using Access Tokens for authentication: Access tokens are opaque credentials for resource access. Never use "this person has a valid access token" as proof of identity — the token may have been issued to a different app.
- Skipping ID Token validation: Always verify the JWT signature,
iss,aud,exp, andnonceclaims before trusting an ID Token. - Ignoring the
subclaim: Use thesub(subject) claim as the stable user identifier in your database, not the email address — emails can change.
When to Use Which
Use OAuth 2.0 alone when your application needs to act on behalf of a user against a third-party API and doesn't need to know who the user is (e.g., a server-side integration). Use OpenID Connect whenever you need to authenticate users — log in, establish sessions, or verify identity. In most modern applications, you'll use both together.
Understanding this boundary is foundational to building secure, standards-compliant web applications. It's one of those concepts that, once clearly understood, changes how you read every auth-related spec and documentation page.