Web Security & OWASP (50 Qs)•Part 3: Authentication, Authorization & Cryptographic Standards (26 - 35)
OAuth 2.0 PKCE (Proof Key for Code Exchange): Why Implicit Flow is dead and how PKCE prevents code interception.
Why the Implicit Flow was Deprecated
In the legacy OAuth 2.0 Implicit Flow, tokens were returned directly in the browser's URL fragment (#access_token=...). This exposed tokens to browser history, proxy access logs, and malicious browser extensions.
Furthermore, on mobile devices, malicious apps could register custom URI schemes (e.g. myapp://oauth) and intercept the Authorization Code in transit.
vbnet
Step 1: Client generates random 43-128 character string:
code_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
Step 2: Client computes SHA-256 hash and base64url-encodes it:
code_challenge = BASE64URL(SHA256(code_verifier))
Step 3: Client redirects to Auth Server with code_challenge:
GET /authorize?client_id=123&code_challenge=xyz...&code_challenge_method=S256
Step 4: Auth Server records code_challenge and returns Authorization Code:
Redirect: myapp://callback?code=AUTH_CODE_789
Step 5: Client exchanges Code + Original code_verifier:
POST /oauth/token
{ "code": "AUTH_CODE_789", "code_verifier": "dBjftJeZ4CVP..." }
Step 6: Auth Server hashes code_verifier and verifies it matches Step 2.
Tokens issued securely!
Even if an attacker intercepts the Authorization Code in Step 4, they cannot redeem it because they do not possess the secret code_verifier stored securely in client memory.