OAuth Best Practices

OAuth 2.0 is a framework, not a turnkey protocol, so implementers must make dozens of security-relevant decisions themselves. Getting those decisions wrong is the leading cause of real-world OAuth vulnerabilities, from authorization code interception to token leakage via referrer headers or browser history. The practices below, largely codified in RFC 9700 (the OAuth 2.0 Security Best Current Practice), apply to almost every deployment regardless of grant type or client platform.

RFC 9700 now mandates Proof Key for Code Exchange (PKCE) for every authorization code flow, not just public clients on mobile and single-page apps. The client generates a random code_verifier, derives a code_challenge via SHA-256, sends the challenge in the authorization request, and later presents the original verifier at the token endpoint so the authorization server can confirm the code redemption came from the same party that started the flow. Separately, the state parameter — a unique, unguessable value tied to the user's session — must be generated per request and validated on return to block cross-site request forgery attacks that trick a victim into completing another attacker's authorization flow.

Access tokens and refresh tokens are bearer credentials: whoever holds them can use them, so where and how they're stored matters as much as how they're issued. For browser-based apps, storing tokens in localStorage or sessionStorage exposes them to any script that runs on the page, so a single cross-site scripting bug anywhere in the app's dependency tree can exfiltrate every active session; httpOnly, Secure, SameSite=Lax cookies scoped to a narrow path are far safer because JavaScript cannot read them. For server-side and native apps, tokens should be encrypted at rest, transmitted only over TLS 1.2+, and access tokens kept short-lived (minutes to a couple of hours) with refresh token rotation so a leaked refresh token has a limited blast radius and reuse can be detected.

Authorization servers must validate redirect_uri against an exact, pre-registered value — not a prefix match, not a wildcard subdomain match — because any looseness here becomes an open redirect that lets an attacker redirect the authorization code or token to a server they control. Clients should likewise request the narrowest set of scopes that the current operation needs rather than a broad, standing grant; a reporting dashboard that only reads order totals should request orders.read, not orders.write or admin scopes it will never use. Combining tight redirect URI matching with least-privilege scoping and, where supported, sender-constrained tokens (DPoP or mutual TLS) dramatically reduces what an attacker can do even if they manage to intercept a code or token.