OAuth 2.0 Is Authorization, Not Authentication
OAuth 2.0 (RFC 6749) is fundamentally a delegated authorization protocol: it lets a user grant a third-party application limited access to their resources on another service — for example, letting a photo-printing app access your Google Photos — without sharing your Google password. The critical, historically common mistake is using a raw OAuth access token as proof of identity, which is unsafe because an access token's scope and audience are not guaranteed to be validated the way an identity token is; this is precisely the gap OpenID Connect (OIDC) was built to close, by layering a standardized identity token (a signed JWT) on top of the OAuth flow. OIDC's ID token includes claims like sub (subject/user ID), iss (issuer), aud (intended audience), and exp (expiry), all of which must be validated by the relying party before trusting the token as proof of who the user is.
Cricket analogy: OAuth is like a player's agent being given a limited permission slip to negotiate only sponsorship deals, not team selection — using that slip as full proof of the player's identity would be a mistake, since it only proves delegated scope, not who signed it.
The Authorization Code Flow with PKCE
For public clients — single-page apps and mobile apps that can't safely keep a client secret — the Authorization Code flow with PKCE (Proof Key for Code Exchange, RFC 7636) is the current best-practice standard, replacing the deprecated Implicit flow. The client generates a random code_verifier, derives a code_challenge (its SHA-256 hash) sent with the initial authorization request, and later exchanges the authorization code for tokens by presenting the original code_verifier; the authorization server verifies the hash matches, proving the token exchange is happening from the same client that initiated the flow. This defeats authorization-code-interception attacks: even if an attacker intercepts the redirect containing the authorization code (e.g., via a malicious app registering the same custom URL scheme on mobile), they cannot complete the token exchange without the original, never-transmitted code_verifier.
Cricket analogy: It's like a stadium issuing a ticket claim receipt (authorization code) that can only be redeemed for the actual ticket by someone who also holds the original purchase confirmation SMS (code_verifier) — intercepting just the receipt isn't enough without that second proof.
// Browser-based SPA: generating PKCE code_verifier and code_challenge
function base64UrlEncode(buffer) {
return btoa(String.fromCharCode(...new Uint8Array(buffer)))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}
async function generatePKCEPair() {
const verifierBytes = crypto.getRandomValues(new Uint8Array(32));
const codeVerifier = base64UrlEncode(verifierBytes);
const encoder = new TextEncoder();
const data = encoder.encode(codeVerifier);
const digest = await crypto.subtle.digest('SHA-256', data);
const codeChallenge = base64UrlEncode(digest);
// Store codeVerifier in sessionStorage; it's needed later at the token exchange step
sessionStorage.setItem('pkce_code_verifier', codeVerifier);
return { codeVerifier, codeChallenge };
}
// Redirect to authorization server
const { codeChallenge } = await generatePKCEPair();
const authUrl = `https://auth.example.com/authorize?` +
`response_type=code&client_id=spa-client&` +
`redirect_uri=${encodeURIComponent('https://app.example.com/callback')}&` +
`scope=openid%20profile&` +
`code_challenge=${codeChallenge}&code_challenge_method=S256&state=${crypto.randomUUID()}`;
window.location = authUrl;Always validate the state parameter on the OAuth callback to prevent CSRF against the authorization flow, and always validate the redirect_uri against an exact allowlist on the authorization server — an open redirect or wildcard-matched redirect URI is one of the most common real-world OAuth misconfigurations leading to authorization code theft.
Common Misconfigurations
Beyond redirect URI validation, a frequent OIDC mistake is failing to validate the ID token's signature, issuer, and audience claims on the relying-party side — accepting any well-formed JWT without checking it was actually signed by the expected issuer's key (fetched from the issuer's /.well-known/jwks.json endpoint) opens the door to forged tokens. Another common flaw is the 'confused deputy' problem in multi-tenant OAuth setups, where an application fails to verify that the aud (audience) claim matches its own client ID, allowing a token legitimately issued for a different, less-trusted client to be replayed against a more sensitive API. OWASP's OAuth 2.0 security guidance (and RFC 9700, the OAuth 2.0 Security Best Current Practice) both stress that access tokens should be short-lived, refresh tokens should be rotated on use (detecting replay if an old refresh token is reused), and implicit flow should be avoided entirely in favor of Authorization Code + PKCE.
Cricket analogy: It's like a ground accepting any laminated card with 'ICC Match Official' printed on it without checking it against the actual issued list from the ICC — no signature verification means forged credentials pass just as easily as real ones.
Always fetch the issuer's signing keys from its /.well-known/jwks.json endpoint (referenced via the OIDC discovery document at /.well-known/openid-configuration) rather than hardcoding a key, and cache with respect to the keys' rotation — hardcoded keys silently break trust validation when the identity provider rotates its signing keys.
- OAuth 2.0 is a delegated authorization protocol; it was never designed to prove identity on its own.
- OpenID Connect layers a signed ID token (JWT) on top of OAuth to provide standardized authentication.
- Authorization Code flow with PKCE is the current best practice for public clients, replacing the deprecated Implicit flow.
- PKCE's code_verifier/code_challenge pair defeats authorization-code-interception attacks.
- Always validate state (CSRF protection) and redirect_uri (exact allowlist) on the OAuth callback.
- ID tokens must be validated for signature, issuer, audience, and expiry before being trusted.
- Access tokens should be short-lived; refresh tokens should rotate on use to detect replay.
Practice what you learned
1. What is the fundamental difference between OAuth 2.0 and OpenID Connect (OIDC)?
2. What problem does PKCE solve for public clients like single-page apps?
3. What is the 'confused deputy' problem in OAuth/OIDC?
4. Where should a relying party fetch an OIDC issuer's signing keys from, rather than hardcoding them?
Was this page helpful?
You May Also Like
Broken Authentication Risks
Understand how authentication mechanisms fail in practice — from credential stuffing to weak session handling — and how OWASP frames these risks.
Session Management Security
Explore how web sessions are created, maintained, and terminated securely, and the common pitfalls — like session fixation and token leakage — that break them.
Multi-Factor Authentication
Understand the categories of authentication factors, how TOTP and WebAuthn work under the hood, and why MFA dramatically reduces account-takeover risk.