auth-security

OAuth 2.1 with PKCE enforces Authorization Code flow using a code verifier and challenge to prevent authorization code interception. Generate a random code verifier, derive its SHA-256 hash as the challenge, send it during authorization, then exchange the authorization code plus verifier for tokens. This protects mobile and single-page applications from code interception attacks.

JWT validation requires explicit algorithm whitelisting (reject 'none'), verification of issuer and audience claims, expiration time checks, and signature validation using JWKS. Never trust the algorithm header; always whitelist acceptable algorithms server-side. Short-lived tokens with rotation reduce exposure if compromised.

Store refresh tokens in HttpOnly, Secure cookies to prevent JavaScript access and XSS theft. Store access tokens in memory or sessionStorage for SPAs. On mobile, use platform-native secure storage. Never store tokens in localStorage; it's vulnerable to XSS attacks and lacks httpOnly protections.

Refresh token rotation issues a new refresh token with each token refresh and invalidates the previous one. This limits the window of exposure if a refresh token is stolen, forces attackers to use compromised tokens quickly before rotation, and detects token replay attacks when old tokens are reused.

OAuth 2.1 mitigates token binding by tying tokens to specific clients and resource servers through audience validation. Audience claims must match the resource server's identifier; tokens issued for one API cannot be used on another. Token binding and explicit scope validation prevent tokens from being used in unintended contexts.

OAuth 2.1 consolidates best practices from RFC 6749 and security extensions, mandates PKCE for all public clients, deprecates implicit and resource owner password flows, and strengthens security defaults. It simplifies the spec by removing weaker flows and making token endpoint authentication mandatory for confidential clients.