OpenID Connect vs OAuth 2.0: What's the Difference and When to Use Each

The Common Confusion

Developers frequently conflate OAuth 2.0 and OpenID Connect (OIDC). They are related but solve different problems. Using the wrong one — or misunderstanding which does what — can lead to subtle but serious security vulnerabilities in your application.

Let's break them down clearly.

OAuth 2.0: Authorization, Not Authentication

OAuth 2.0 is an authorization framework defined in RFC 6749. It allows a third-party application to obtain limited access to a resource on behalf of a user — without exposing the user's credentials.

Classic example: "Allow this app to read my Google Drive files." The user grants permission, and the app receives an access token it can use to call the Google Drive API.

What OAuth 2.0 does not define is how to answer the question: "Who is this user?" Access tokens are opaque by design — they prove permission, not identity.

OpenID Connect: Identity Layer on Top of OAuth 2.0

OpenID Connect 1.0 is a thin identity layer built on top of OAuth 2.0. Published by the OpenID Foundation, it adds:

• An ID Token — a signed JWT containing claims about the authenticated user (sub, name, email, etc.)
• A UserInfo endpoint — a standardized API to fetch additional user profile data.
• A Discovery document — published at /.well-known/openid-configuration, describing the provider's capabilities.
• Standardized scopes like openid, profile, and email.

Side-by-Side Comparison

Feature	OAuth 2.0	OpenID Connect
Primary purpose	Authorization	Authentication + Authorization
Token issued	Access Token	Access Token + ID Token
Token format	Opaque or JWT (varies)	JWT (standardized)
User identity	Not defined	Standardized via ID Token
Discovery	Not standardized	/.well-known/openid-configuration
Use case	API access delegation	"Sign in with X" flows

The Four OAuth 2.0 Grant Types

1. Authorization Code: The most secure flow for web apps. The app receives a short-lived code it exchanges server-side for tokens.
2. Authorization Code + PKCE: The recommended flow for mobile and single-page apps. PKCE prevents authorization code interception attacks.
3. Client Credentials: For machine-to-machine (M2M) authentication where no user is involved.
4. Device Authorization: For devices with limited input (smart TVs, CLIs) that display a code for the user to enter on a separate device.

The Implicit Flow and Resource Owner Password grant are now deprecated in OAuth 2.1 and should not be used in new implementations.

When to Use Which

• Use OAuth 2.0 alone when you need to grant API access to a third party without caring about user identity (e.g., a CI/CD pipeline accessing your repo).
• Use OpenID Connect when you need to authenticate users and establish who they are — powering "Sign in with Google/GitHub/Apple" style flows.
• In most modern web applications, you'll use both together: OIDC for login, OAuth 2.0 for authorizing downstream API calls.

Key Takeaway

A helpful mental model: OAuth 2.0 gives you a hotel key card (access to a room), while OpenID Connect tells you the guest's name on the reservation. One is about permission; the other is about identity. Understanding the distinction makes for significantly more secure application architecture.