Bearer Tokens: What 'Bearer' Means and What It Costs You

Why the word "Bearer"

HTTP defines multiple authentication schemes. The scheme name appears before the credential in the Authorization header and tells the server how to interpret what follows:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
Authorization: Digest username="alice", realm="example.com", ...

Bearer tokens come from OAuth 2.0 (RFC 6750). "Bearer" means whoever bears (holds) this token is granted access. The server does not check who is presenting the token — only that the token is valid.

| Scheme | Header Example | Meaning | |--------|---------------|---------| | Basic | Basic QWxhZGRpbjpvc... | Base64-encoded username:password | | Bearer | Bearer eyJhbGciOi... | OAuth 2.0 access token (often a JWT) | | Digest | Digest username="alice"... | Challenge-response, avoids sending password in clear |

The token lifecycle in practice

In an OAuth 2.0 flow, the access token is short-lived (minutes to hours). A refresh token (longer-lived, stored securely) is used to obtain new access tokens without re-authentication.

1. User authenticates → authorization server issues:
   access_token (15 min TTL) + refresh_token (30 day TTL)

2. Client sends requests:
   Authorization: Bearer <access_token>

3. access_token expires → client uses refresh_token to get new tokens:
   POST /token { grant_type: refresh_token, refresh_token: <...> }
   → New access_token + optionally new refresh_token (rotation)

4. User logs out → refresh_token is revoked server-side
   Future refresh attempts fail → user must re-authenticate

The access token is typically a JWT — stateless, self-describing, verifiable by signature alone. The refresh token is opaque — a random string the authorization server maps to a user session in its database. Revocation of a refresh token is immediate. Revocation of an access token requires either waiting for expiry or maintaining a denylist.

Where to store tokens in a browser

This is the most common source of security mistakes in SPA authentication.

localStorage: persists across tabs and browser restarts. Accessible by any JavaScript on your domain. If your site has an XSS vulnerability, any injected script can read the token and exfiltrate it.

sessionStorage: cleared when the tab closes. Still accessible by JavaScript — XSS can still steal it.

Memory (JavaScript variable): cleared on page refresh. Not accessible by XSS from other documents. Requires re-authentication after refresh unless you use a silent token renewal strategy (hidden iframe or background fetch to the authorization server).

HttpOnly cookie: not accessible by JavaScript at all. Protects against XSS token theft. Introduces CSRF risk — mitigated by SameSite=Strict/Lax. Works for same-domain SPAs; has complications for cross-domain APIs.

// On app startup — refresh token is sent automatically via cookie
async function initAuth() {
    const response = await fetch('/auth/refresh', {
        method: 'POST',
        credentials: 'include',  // sends the HttpOnly cookie
    });
    if (response.ok) {
        const { access_token } = await response.json();
        setAccessToken(access_token);  // store in memory
    }
}

// On API calls — manually attach the in-memory access token
async function apiCall(url) {
    return fetch(url, {
        headers: { 'Authorization': `Bearer ${getAccessToken()}` }
    });
}

Proof-of-possession: the alternative to bearer

Bearer tokens have a fundamental weakness: a stolen token is immediately usable. Proof-of-Possession (PoP) tokens bind the token to the client's private key. The server verifies that the request was signed by the holder of the key the token was issued to.

Authorization: PoP <token>
DPoP: <signed proof JWT>

DPoP (Demonstrating Proof of Possession, RFC 9449) is the OAuth 2.0 extension for this. The access token is bound to a public key. Each request includes a signed proof JWT proving the sender holds the private key. Even if an attacker captures the token and the proof JWT, they cannot reuse either — the proof JWT is request-specific (includes the HTTP method, URL, and a nonce).

DPoP is increasingly adopted for high-security contexts (financial APIs, FAPI compliance). For most applications, bearer tokens with short TTLs and HTTPS are sufficient.