Bearer Token

What is a bearer token?

A bearer token is an access credential where whoever possesses (“bears”) the token can use it — the server grants access to any request that presents a valid token, without further proof that the presenter is the legitimate owner. The analogy is cash: whoever holds a banknote can spend it, no ID required. Bearer tokens are the dominant pattern in modern API authentication — an OAuth 2.0 access token (often a JWT) sent in the HTTP Authorization: Bearer <token> header is a bearer token — because they’re simple and stateless: the server just validates the token and serves the request, no session lookup needed for self-contained tokens.

The core property — and its inherent risk

The defining characteristic, “possession = access,” is both why bearer tokens are convenient and why they’re risky. Convenient because there’s no complex per-request cryptographic proof of ownership — present the token, get access — which makes APIs simple and scalable. Risky because if a bearer token is stolen or intercepted, the thief can use it exactly as the legitimate owner would, with nothing to stop them until the token expires or is revoked. There’s no binding between the token and a particular client, so an attacker who obtains the token (by sniffing traffic, reading it from logs, stealing it from browser storage, or via XSS) simply replays it. This is fundamentally different from a scheme where the client must prove possession of a key to use the credential — with a bearer token, holding it is the authorization. That property dictates every best practice around them.

Protecting bearer tokens — the disciplines that matter

Because possession is everything, defense focuses on preventing interception and limiting the damage window. The non-negotiables: always transmit over TLS/HTTPS — a bearer token sent over plaintext HTTP can be sniffed and replayed, so TLS is mandatory, not optional; never put tokens in URLs (they leak into server logs, browser history, and Referer headers) — use the Authorization header; keep them short-lived — a short expiry (minutes to an hour for access tokens) means a stolen token is useful only briefly, which is why access tokens are deliberately short-lived and paired with a longer-lived refresh token (stored more securely) to get new ones; store them carefully on the client — in browsers, tokens in localStorage are readable by any XSS, so more secure patterns (in-memory, or httpOnly cookies with CSRF protection) are preferred for sensitive apps; and support revocation so a compromised token can be invalidated before expiry. For higher-security needs, sender-constrained tokens (DPoP, or mutual-TLS-bound tokens) bind a token to a specific client key so a stolen token can’t be replayed by someone else — turning off the pure-bearer property — and are increasingly recommended where the stakes justify the complexity. The recurring mistakes: transmitting bearer tokens over non-TLS connections or in URLs (making interception trivial), long-lived access tokens (a stolen one stays valid for ages), insecure client storage exposing tokens to XSS, and treating a self-contained JWT bearer token as impossible to misuse when in fact anyone holding it can.

What people get wrong

• Transmitting over non-TLS or in URLs — a bearer token is like cash; sent over plaintext HTTP or embedded in a URL it’s trivially sniffed or logged and then replayed. Always use TLS and the Authorization header.
• Long-lived access tokens: possession = access, so a stolen long-lived token is a long-lived compromise — keep access tokens short and refresh them via a more securely stored refresh token.
• Insecure client storage — tokens in localStorage are exposed to any XSS; for sensitive apps use in-memory or httpOnly-cookie storage, and consider sender-constrained (DPoP/mTLS) tokens to defeat replay.

Primary source: RFC 6750: OAuth 2.0 Bearer Token Usage