Skip to content

OAuth2 vs OIDC

1. Decision

Use OAuth 2.0 strictly as an Authorization Framework to grant third-party applications limited, scoped access to protected API resources on behalf of a user; use OpenID Connect (OIDC) built on top of OAuth 2.0 as an Authentication Protocol to verify user identity and achieve Single Sign-On (SSO).

2. 30-Second Answer

OAuth 2.0 and OIDC solve fundamentally different security requirements. OAuth 2.0 is an Authorization framework. It grants a client application a scoped Access Token allowing it to perform actions on a Resource Server on behalf of a Resource Owner (e.g. "Allow App X to read my Google Drive files"). OAuth 2.0 answers what the client is allowed to access, but does NOT define who the user is or how they authenticated. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It introduces a standardized ID Token (a signed JWT) alongside the Access Token, providing user profile claims (sub, email, name) and standardized endpoints (/.well-known/openid-configuration, /userinfo) to achieve Single Sign-On (SSO).

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
OAuth 2.0 (Authorization Framework) Delegated API access permissions, third-party developer API access, scoped access tokens User authentication, Single Sign-On (SSO), verifying user identity claims Low (Token presentation to API Gateway) High (Stateless bearer access token validation) Scoped API access control Medium
OpenID Connect - OIDC (Identity Layer) User authentication, Single Sign-On (SSO), corporate Okta/Auth0 login, social sign-in ("Log in with Google") Simple machine-to-machine internal RPCs without user identity context Low (ID Token JWT verified locally via JWKS) High (Federated identity providers) Standardized user profile claims (sub, email) Medium to High (OIDC Provider integration)

4. Selection Rules

Requirement Best Choice Rationale / Example
User Authentication / Single Sign-On (SSO) OpenID Connect (OIDC) "Log in with Google / Auth0" returns a signed id_token (JWT) containing user identity
Delegated Third-Party API Access OAuth 2.0 Grant Spotify app permission to read user's playlists via access_token with playlist-read scope
Single-Page App (SPA) / Mobile Auth Flow OIDC Authorization Code Flow + PKCE Use Authorization Code Flow with PKCE extension to securely authenticate native/web apps
Server-to-Server Machine Auth OAuth 2.0 Client Credentials Grant Microservice A authenticates to Microservice B using client_id and client_secret
Standardized User Profile Claims Parsing OpenID Connect (OIDC) Decode id_token JWT claims (sub, email, email_verified) using standard OIDC specs

5. Tradeoffs

  1. Delegated Authorization vs Identity Authentication
  2. Gain (OAuth2): Securely delegates API permissions without sharing user passwords.
  3. Lose (OAuth2): Does not provide user identity claims; using OAuth2 for authentication leads to security anti-patterns.
  4. Standardized Identity Layer (OIDC) vs Custom User Profile APIs
  5. Gain (OIDC): Standardized ID Token JWT, discovery metadata (/.well-known/openid-configuration), and UserInfo endpoint.
  6. Lose (OIDC): Requires setting up an OIDC Identity Provider (Auth0, Okta, Keycloak).
  7. PKCE Security Extension vs Implicit Grant Vulnerabilities
  8. Gain (PKCE): Protects mobile apps and SPAs from authorization code interception attacks.
  9. Lose (PKCE): Requires client code to generate code verifier and code challenge hashes per login flow.
  10. Access Token vs ID Token Separation
  11. Gain: Access Tokens are meant for API Resource Servers; ID Tokens are meant only for the Client application UI.
  12. Lose: Misunderstanding token roles causes developers to pass ID Tokens to backend API endpoints.
  13. Centralized Identity Provider (IdP) Dependencies
  14. Gain: Centralized SSO login, Multi-Factor Authentication (MFA), and password management.
  15. Lose: External IdP downtime blocks user login across all integrated systems.

6. Interview Counter Questions

  1. Why is "Using OAuth 2.0 for Authentication" an architectural security anti-pattern?
  2. What is the difference between an Access Token and an ID Token in OIDC?
  3. How does the OAuth 2.0 Authorization Code Flow with PKCE (Proof Key for Code Exchange) work?
  4. What are the 4 core roles defined in OAuth 2.0 (Resource Owner, Resource Server, Client, Authorization Server)?
  5. What are the 4 main OAuth 2.0 Grant Types (Authorization Code, Client Credentials, Refresh Token, Implicit [Deprecated])?
  6. What is PKCE and why is the Implicit Grant flow deprecated in modern OAuth 2.0 security standards?
  7. How does the OIDC Discovery Endpoint (/.well-known/openid-configuration) simplify client integrations?
  8. What is the role of the state parameter in OAuth 2.0 authorization requests (CSRF defense)?
  9. What is Token Exchange (RFC 8693) in microservices?
  10. How do scopes in OAuth 2.0 differ from user roles/permissions in RBAC?

7. Gold Standard Answers

  1. OAuth 2.0 is an authorization framework designed to grant access to resources, not verify identity. An Access Token presence does not tell the client who authenticated, when they authenticated, or how (MFA). OIDC adds the ID Token to solve this cleanly.
  2. Access Token: Opaque string or JWT intended for the Resource Server (API) to authorize requests. ID Token: Signed JWT intended for the Client App containing user identity claims (sub, email).
  3. Client generates a random code_verifier, hashes it to create code_challenge, and sends challenge with auth request. Auth server returns authorization code. Client exchanges code + original code_verifier for tokens.
  4. Resource Owner: The User. Client: The app requesting access. Authorization Server: Issues tokens (Okta/Auth0). Resource Server: The API hosting protected user data.
  5. (1) Authorization Code + PKCE (Mobile/Web apps with user), (2) Client Credentials (Machine-to-machine), (3) Refresh Token (Re-issuing expired access tokens), (4) Implicit (Deprecated due to URL hash token leakage).
  6. Implicit Grant returned access tokens directly in URL fragments (#access_token=...), exposing them to browser history and referral leakages. PKCE replaces it by exchanging authorization codes securely using cryptographically verified code challenges.
  7. It returns a standardized JSON document describing all IdP endpoints (authorization_endpoint, token_endpoint, jwks_uri, scopes_supported), allowing client SDKs to auto-configure cleanly.
  8. The state parameter is an unguessable random token generated by the client and verified upon callback return. It binds the authorization response to the original browser session, blocking Cross-Site Request Forgery (CSRF).
  9. Token Exchange allows a microservice to exchange an incoming user Access Token for a downgraded, scoped internal token to safely call downstream microservices without forwarding the full user credential context.
  10. OAuth2 Scopes define permissions granted to the application client (e.g. read:contacts). User Roles (RBAC) define permissions owned by the user (e.g. ADMIN). Effective permission is the intersection of both.

8. Common Mistakes

  • Using OAuth 2.0 Access Tokens to authenticate user identity instead of OIDC ID Tokens.
  • Using the deprecated Implicit Grant flow for Single Page Applications instead of Authorization Code Flow with PKCE.
  • Passing the OIDC ID Token to backend API endpoints instead of the OAuth 2.0 Access Token.
  • Omitting the state parameter in authorization requests, exposing login flows to CSRF attacks.
  • Confusing OAuth2 Scopes (client app permissions) with User RBAC Roles (end-user privileges).

9. Keywords

OAuth 2.0, OpenID Connect, OIDC, Access Token, ID Token, Authorization Code Flow, PKCE, Client Credentials, Resource Owner, Resource Server, Authorization Server, PKCE Code Challenge, State Parameter, CSRF, Scopes, JWKS.

10. Cheat Sheet

  • Core Difference: OAuth 2.0 = Authorization (API Permissions); OIDC = Authentication (User Identity & Single Sign-On).
  • Token Destination: ID Token (JWT) is for the Client App UI; Access Token is for the Backend API Resource Server.
  • Web & Mobile Flow: Always use Authorization Code Flow with PKCE. Never use the deprecated Implicit Grant!
  • Machine-to-Machine Flow: Use Client Credentials Grant (client_id + client_secret) for backend microservice-to-microservice auth.
  • CSRF Defense: Always validate the random state parameter in OAuth callback handlers.
  • Discovery Endpoint: Fetch /.well-known/openid-configuration to auto-discover IdP endpoints and JWKS URIs.

11. Related Decisions