This chapter explains why OAuth 2.0 centers on bearer tokens and what that means for security. By removing OAuth 1.0’s brittle message-signing requirements and relying instead on secure transport, OAuth 2.0 simplifies implementation but makes the confidentiality and integrity guarantees of TLS nonnegotiable. Bearer tokens behave much like session cookies: whoever holds them can use them. While a stolen token is generally less catastrophic than a stolen password, the chapter stresses careful design of tokens and codes, and disciplined handling across the system to minimize impact if they leak.
The text catalogs common token threats—forgery, replay, redirect/misuse across services, and information disclosure—and maps practical defenses to each OAuth role. Always use TLS in transit. Clients should practice least privilege by requesting minimal scopes, prefer short-lived access tokens backed by refresh tokens, and store tokens securely (ideally only in transient memory). Authorization servers should hash stored token values, generate high-entropy random tokens, keep access-token lifetimes short, issue refresh tokens when longer access is needed, and audit issuance, use, and revocation without logging raw tokens. Resource servers should scrub tokens from logs, validate and constrain scope precisely, avoid “superuser” tokens, consider cache trade-offs, and apply rate limiting to reduce token fishing.
Beyond access tokens, the chapter addresses authorization code safety. Because public and native clients can’t safely keep a client secret, they are exposed to code interception. Proof Key for Code Exchange (PKCE) counters this by binding the authorization request to the token request: the client generates a secret verifier, sends a derived challenge with the authorization request, and later proves possession by presenting the verifier so the server can recompute and compare. Servers must support the SHA-256 method; clients should prefer it. PKCE is simple to add, works for public and confidential clients, and—combined with strict transport security, scoped tokens, short lifetimes, and careful storage—significantly reduces common OAuth token vulnerabilities.
PKCE code_challenge
PKCE code_verifier
Comparing the code_verifier with the code_challenge
PKCE detailed view
FAQ
What is a bearer token in OAuth 2.0?A bearer token is a string that grants access to a resource to whoever presents it. Unlike OAuth 1.0 tokens, bearer tokens don’t require a per-request signature; security relies on using TLS during issuance and use.How are bearer tokens similar to and different from browser cookies?Both are plaintext strings that rely on TLS for confidentiality and integrity in transit. Unlike cookies, OAuth clients don’t get automatic same-origin protections, so tokens can be sent to multiple domains unless the client and servers enforce boundaries.What are the most common bearer token threats?- Token forgery: crafting or altering tokens to gain unauthorized access. - Token replay: reusing an old or intercepted token. - Token redirect: using a token meant for one API at a different API that improperly accepts it. - Token disclosure: leaking sensitive information embedded in a token.Why is TLS mandatory when using bearer tokens?Because possession implies use, anyone who captures a bearer token can act with its privileges. TLS provides confidentiality and message integrity between endpoints, preventing eavesdropping and tampering during token issuance and API calls.How can clients reduce the impact of a stolen token?- Request the least privilege (scopes) needed. - Prefer short-lived access tokens and use refresh tokens when longer access is needed. - Store tokens securely and, where possible, only in transient memory to limit exposure if storage is compromised.What should authorization servers do to protect tokens at rest?- Store only a cryptographic hash of token values (for example, SHA-256), not the raw token. - Issue high-entropy, unpredictable tokens (at least 128 bits). - Keep access tokens short-lived; use refresh tokens for longevity. - Log issuance/usage/revocation securely without recording raw token values and monitor for anomalies.How should protected resources (APIs) handle bearer tokens safely?- Validate tokens carefully and require specific, minimal scopes per endpoint. - Avoid special “god” tokens with broad privileges. - Scrub tokens from request/response logs and analytics. - Use rate limiting and consider cautious caching of introspection results. - Keep tokens only in transient memory where feasible.Is a stolen bearer token as bad as a stolen password?Typically no. A well-designed token is limited in scope and lifetime, reducing blast radius. Passwords often grant broad, long-lived access; a short-lived, narrowly scoped token minimizes damage.What is PKCE and how does it protect authorization codes?PKCE binds the authorization request to the token request using a one-time secret (code_verifier) and its derived value (code_challenge). The client sends the challenge during authorization and later proves possession by sending the verifier at the token endpoint, thwarting code interception.Who should use PKCE, and which method is recommended?All public clients should use PKCE, and confidential clients benefit from it as well. Servers must support the S256 method; clients should prefer S256 and use plain only if S256 isn’t technically possible.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
OAuth 2 in Action ebook for free
