OAuth 2.0 Deep Dive
Master all OAuth 2.0 flows: Authorization Code, Client Credentials, and more. OAuth 2.0 Guide →
OAuth 2.0 vs OpenID Connect (OIDC) - What's the Difference?
THE KEY DISTINCTION
OAuth 2.0 is for Authorization (what can you access?). OpenID Connect is for Authentication (who are you?). OIDC is an identity layer built on top of OAuth 2.0.
The Nightclub Analogy: OAuth 2.0 is like showing a wristband that proves you paid for VIP access—the bouncer doesn’t care who you are, just that you have access. OpenID Connect is like showing your driver’s license—the bouncer now knows your name, age, and photo, confirming your identity before granting VIP access.
Quick Comparison Table
Section titled “Quick Comparison Table”| Aspect | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Purpose | Authorization | Authentication + Authorization |
| Question Answered | ”What can this app access?" | "Who is this user?” |
| Token Type | Access Token | ID Token + Access Token |
| Token Format | Opaque or JWT | JWT (always) |
| User Info | Optional (via API call) | Built-in (ID Token claims) |
| Use Case | API access, third-party integrations | Single Sign-On, user login |
| Specification | RFC 6749, RFC 6750 | OpenID Foundation spec |
Understanding OAuth 2.0
Section titled “Understanding OAuth 2.0”OAuth 2.0 was designed to solve the delegated authorization problem. Before OAuth, if you wanted a third-party app to access your data, you had to give it your password.
The Problem OAuth Solves
Section titled “The Problem OAuth Solves”Imagine you want a photo printing service to access your Google Photos. Without OAuth:
- ❌ Give the printing service your Google password
- ❌ The service has full access to your entire Google account
- ❌ You can’t revoke access without changing your password
- ❌ If the service is compromised, your entire account is at risk
With OAuth 2.0:
- ✅ You authorize specific, limited access (only photos, not email)
- ✅ The service receives a token, never your password
- ✅ You can revoke access at any time
- ✅ Tokens can expire automatically
OAuth 2.0 Flow (Authorization Code)
Section titled “OAuth 2.0 Flow (Authorization Code)”1
Authorization Request
User clicks “Connect with Google.” App redirects to Google’s authorization server with requested scopes (e.g., “read photos”).
2
User Consent
User logs into Google (if needed) and sees a consent screen: “Photo Printer wants to access your photos. Allow?“
3
Authorization Code
User approves. Google redirects back to the app with a short-lived authorization code.
4
Token Exchange
App exchanges the authorization code for an Access Token (server-to-server, secure).
5
API Access
App uses the Access Token to call Google Photos API. Token proves authorization, not identity.
OAuth 2.0 Limitations
Section titled “OAuth 2.0 Limitations”OAuth 2.0 has a critical limitation: it doesn’t tell you WHO the user is.
Access Token: "ey...abc123"Meaning: "Bearer of this token can read photos"Missing: Who is the user? What's their name? Email? User ID?This is where OpenID Connect comes in.
Understanding OpenID Connect
Section titled “Understanding OpenID Connect”OpenID Connect (OIDC) extends OAuth 2.0 by adding an identity layer. It answers the question: “Who is this user?”
What OIDC Adds to OAuth 2.0
Section titled “What OIDC Adds to OAuth 2.0”| OAuth 2.0 Component | OIDC Addition |
|---|---|
| Access Token | ID Token (user identity) |
Scopes (read, write) | openid, profile, email scopes |
| Token endpoint | UserInfo endpoint |
| - | Discovery document (.well-known/openid-configuration) |
| - | Standard claims (sub, name, email, picture) |
The ID Token
Section titled “The ID Token”The ID Token is a JWT (JSON Web Token) containing claims about the authenticated user:
{ "iss": "https://accounts.google.com", "sub": "110248495921238986420", "aud": "your-client-id.apps.googleusercontent.com", "exp": 1735142400, "iat": 1735138800, "name": "Jane Developer", "email": "jane@example.com", "email_verified": true, "picture": "https://lh3.googleusercontent.com/..."}Key claims:
- iss: Who issued this token (Google, Okta, Auth0, etc.)
- sub: Unique identifier for the user
- aud: Which app this token is for (prevents token misuse)
- exp/iat: Expiration and issued-at timestamps
- name, email, picture: User profile information
OIDC Flow (Authorization Code)
Section titled “OIDC Flow (Authorization Code)”OIDC uses the same flow as OAuth 2.0, with key differences:
1
Authorization Request with OIDC Scopes
Include openid scope (required), plus profile and email as needed.
2
Token Exchange Returns ID Token
Server returns both an Access Token and an ID Token.
3
Validate the ID Token
Verify signature, check issuer, audience, expiration. The ID Token is cryptographically signed proof of identity.
4
Optional: UserInfo Endpoint
For additional claims not in the ID Token, call the UserInfo endpoint with the Access Token.
When to Use Each Protocol
Section titled “When to Use Each Protocol”OAuth 2.0 alone is sufficient when you need:
- ✅ API access without user identity (machine-to-machine)
- ✅ Third-party integrations (Slack posting to your channel)
- ✅ Access delegation without login
- ✅ Service-to-service communication
Example: A scheduling app that posts to your Google Calendar. It doesn’t need to know who you are—just that you authorized calendar access.
OpenID Connect is required when you need:
- ✅ User login / Single Sign-On (SSO)
- ✅ User profile information (name, email, picture)
- ✅ Session management
- ✅ Cross-domain authentication
Example: “Login with Google” on your web app. You need to know the user’s identity to create their account and personalize their experience.
OAuth 2.0 + OIDC together (the most common pattern):
- ✅ Login users AND access their resources
- ✅ Build a complete authentication/authorization system
- ✅ Implement SSO with API access
Example: A project management app that logs you in with Okta (OIDC) and accesses your Jira issues (OAuth 2.0 API).
Common Mistakes to Avoid
Section titled “Common Mistakes to Avoid”❌ Mistake 1: Using Access Tokens for Authentication
Section titled “❌ Mistake 1: Using Access Tokens for Authentication”// WRONG - Never trust access tokens for identityconst user = await getUserFromAccessToken(accessToken);Access tokens are for API access, not identity. Always validate the ID Token for user identity.
❌ Mistake 2: Not Validating ID Tokens
Section titled “❌ Mistake 2: Not Validating ID Tokens”// WRONG - Never skip validationconst claims = jwt.decode(idToken); // Just decodes, no verification!
// RIGHT - Always verify signatureconst claims = jwt.verify(idToken, publicKey, { algorithms: ['RS256'] });❌ Mistake 3: Ignoring the Audience Claim
Section titled “❌ Mistake 3: Ignoring the Audience Claim”ID tokens are minted for specific clients. If your client_id isn’t in the aud claim, reject the token.
❌ Mistake 4: Storing Tokens Insecurely
Section titled “❌ Mistake 4: Storing Tokens Insecurely”| Token Type | Browser Storage | Recommendation |
|---|---|---|
| Access Token | ❌ localStorage | ✅ Memory only, or httpOnly cookie |
| ID Token | ❌ localStorage | ✅ Validate and discard, or httpOnly cookie |
| Refresh Token | ❌ NEVER in browser | ✅ Server-side only |
Protocol Standards Reference
Section titled “Protocol Standards Reference”| Protocol | Specification | Key Documents |
|---|---|---|
| OAuth 2.0 | IETF RFC 6749 | RFC 6749, RFC 6750 |
| OAuth 2.1 | Draft | Consolidates OAuth 2.0 best practices |
| OpenID Connect | OpenID Foundation | Core Spec |
| PKCE | RFC 7636 | Required for public clients |
| DPoP | RFC 9449 | Sender-constrained tokens |
Next Steps
Section titled “Next Steps”OpenID Connect Deep Dive
Learn ID Token validation, discovery, and session management. OIDC Guide →
Implement SSO
Put it all together with a Single Sign-On implementation. SSO Patterns →
Secure Your Tokens
Learn about PKCE, DPoP, and token security best practices. Token Security →