OAuth and PKCE

A good article - https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce

--- chatGPT

Below are interview-ready, senior-level notes on OAuth 2.0 & PKCE, written so you can revise in 15–20 minutes before a Microsoft interview.

OAuth 2.0 & PKCE — Interview-Ready Notes

1. What problem does OAuth solve?

OAuth 2.0 is an authorization framework that allows a user to grant limited access to a client application without sharing credentials.

Key idea

“App gets access to resources, not the user’s password.”

2. Core OAuth Roles (very important)

Role Description
Resource Owner The user
Client App requesting access (SPA, mobile, backend)
Authorization Server Issues tokens (Azure AD, Google, Auth0)
Resource Server API being accessed

👉 Interview tip: OAuth is about authorization, not authentication.

3. Tokens in OAuth

Token Purpose
Access Token Sent to API (Authorization: Bearer)
Refresh Token Used to get new access tokens
ID Token OIDC only (authentication info)

OAuth does NOT define token format (JWT is common but optional).

4. OAuth Grant Types (focus areas)

Grant Type Status Notes
Authorization Code ✅ Recommended Secure, supports backend
Authorization Code + PKCE ✅ Best for SPA/Mobile No client secret
Implicit ❌ Deprecated Tokens in URL (unsafe)
Client Credentials ✅ Server-to-server No user
Resource Owner Password ❌ Deprecated User gives password

5. Authorization Code Flow (Baseline)

Steps

  1. Client redirects user to Authorization Server

  2. User authenticates & consents

  3. Server redirects back with authorization code

  4. Client exchanges code for access token

Why it’s secure

6. Why PKCE exists (key interview question)

The Problem

SPAs and mobile apps:

PKCE Solution

Proves that the app exchanging the code is the same app that requested it.

7. PKCE Concepts (must know terms)

Term Meaning
code_verifier Random secret generated by client
code_challenge Hashed version of verifier
S256 SHA-256 hash method (recommended)

8. OAuth Authorization Code + PKCE Flow

Step-by-Step

  1. Client generates code_verifier

  2. Client creates code_challenge = SHA256(verifier)

  3. Redirects user with code_challenge

  4. Auth server stores challenge

  5. Auth server returns authorization code

  6. Client sends code + code_verifier

  7. Server validates → issues access token

Security Gain

✔ Even if code is stolen, attacker cannot redeem it

9. PKCE vs Client Secret

Scenario Client Secret PKCE
SPA ❌ Unsafe ✅ Required
Mobile App ❌ Unsafe ✅ Required
Backend ✅ Safe Optional
Public Client ❌ ✅

👉 Microsoft likes this line:

“PKCE replaces the need for a client secret in public clients.”

10. OAuth vs OIDC (classic confusion)

OAuth 2.0 OpenID Connect
Authorization Authentication
Access token ID token
API access User identity
No user info User claims

OIDC = OAuth + identity layer

11. Common Interview Traps & Correct Answers

❌ “OAuth is authentication”

✅ OAuth is authorization. Authentication is added via OIDC.

❌ “JWT is OAuth”

✅ OAuth doesn’t mandate JWT. JWT is just a token format.

❌ “Implicit flow is fine for SPAs”

✅ Implicit flow is deprecated.

Use Authorization Code + PKCE.

12. Security Best Practices (senior-level)

13. Real-World Example (Microsoft-style)

SPA + Azure AD

14. One-Line Summary (perfect closing answer)

“OAuth 2.0 is an authorization framework, and PKCE is a security extension that prevents authorization-code interception in public clients like SPAs and mobile apps.”

If you want next: