- RFC 6750: Bearer Token UsageJones, Hardt (IETF, October 2012) - updated by RFC 8996 and RFC 9700
- RFC 9700, section 4.3.2the MUST NOT on query-parameter tokens that tightens this spec
- RFC 9068: JWT Profile for OAuth 2.0 Access Tokenswhat a verifiable access token looks like - the manufacture/modification countermeasure
- RFC 9449: DPoPFett et al. (IETF, September 2023) - the bearer model's successor for browser and native clients
RFC 6750 (Jones, Hardt; October 2012) defines how OAuth access tokens travel once you have them. Its core term is the whole threat model in one line: a bearer token is "a security token with the property that any party in possession of the token (a 'bearer') can use the token in any way that any other party in possession of it can" (section 1.2). No key, no proof, no questions. Whoever holds it, is you.
That property makes bearer tokens pure cargo: everything about using them safely reduces to keeping them secret and short-lived. TLS is "mandatory to implement and use" (section 1), and the document's summary advice (§5.3) is a list of ways to shrink the window between a token leaking and a token expiring. Everything after bearer - DPoP, mTLS, certificate-bound tokens - exists to replace "whoever holds it" with "whoever can prove possession".
Section 2 defines exactly three methods and forbids combining them: "clients MUST NOT use more than one method to transmit the token in each request". Their status is deliberately uneven.
| Method | Shape | Status |
|---|---|---|
| Authorization header section 2.1 | Authorization: Bearer eyJhbGci... | The default: clients SHOULD use it, and "resource servers MUST support this method" - the only method with a MUST-support obligation |
| Form-encoded body section 2.2 | access_token=... in a form POST | SHOULD NOT - only where browsers cannot set headers, under strict conditions (form-urlencoded, single-part, ASCII, no GET; "the 'GET' method MUST NOT be used") |
| URI query parameter section 2.3 | GET /things?access_token=... | SHOULD NOT here - and upgraded to "clients MUST NOT" by RFC 9700 §4.3.2, because URLs leak into history, logs, and referrers no matter how careful you are |
The query parameter survives in the wild mostly via video players and download links that cannot set headers. When you must use it, 6750's own band-aids apply: send Cache-Control: no-store on the request and expect Cache-Control: private on success responses (2.3) - and keep lifetimes short: "token servers SHOULD issue short-lived (one hour or less) bearer tokens" (§5.3).
When a protected request fails, the resource server "MUST include the HTTP 'WWW-Authenticate' response header field" (section 3) - and when a token was presented but failed, the challenge SHOULD say why. Clients that ignore this header fly blind; it is the API's only error channel.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"| Error (3.1) | Means | Status |
|---|---|---|
invalid_request | Missing parameter, unsupported value, repeated parameter, multiple token methods, or otherwise malformed | 400 |
invalid_token | "The access token provided is expired, revoked, malformed, or invalid for other reasons" - the client MAY refresh and retry | 401 |
insufficient_scope | "The request requires higher privileges than provided by the access token"; the challenge MAY carry the needed scope | 403 |
Status codes per §3.1, where all three are SHOULDs, not mandates. The quiet rule underneath: if the request carries no authentication at all, the server "SHOULD NOT include an error code or other error information" (3.1) - error detail is for authenticated callers, not for probes.
Section 5.1 names four threats, "based on NIST Special Publication 800-63". Each has a matching discipline, and the match is the useful part.
| Threat (5.1) | The move | Countermeasure |
|---|---|---|
| Token manufacture/modification | Forge a token or edit one - extend its validity, widen its scope | Integrity the server can verify: unguessable opaque tokens (5.2) or signed JWTs (RFC 9068) |
| Token disclosure | Read the token in transit, storage, logs, or page URLs | TLS everywhere; "bearer tokens MUST NOT be stored in cookies that can be sent in the clear" (5.2); never in URLs - and in a browser, storage is its own threat model (RFC 10017 §8) |
| Token redirect | Use a token minted for one resource server against another that accepts it | Audience restriction: put the intended recipient in the token (5.2; the aud claim in RFC 9068) and have servers enforce it |
| Token replay | Re-use a captured token while it is still valid | Short lifetimes - "token servers SHOULD issue short-lived (one hour or less) bearer tokens" (5.3) - then sender-constraining for the remainder of the risk |
Read as a program: bearer security is lifetimes plus audience plus hygiene, and even done perfectly it converges on "the window is small", never "the window is closed".
Sender-constrained tokens close the model's hole by binding each token to a key only the legitimate client holds, so a stolen token is a dead weight:
mTLS (RFC 8705). The token is bound to a client certificate - the AS embeds the certificate's thumbprint in a cnf claim, and the resource server requires the request to arrive over mutual TLS with the same certificate. The bank-grade route: powerful, operationally heavy, impractical for browsers.
DPoP (RFC 9449). The same binding in application space: the client signs a per-request proof JWT with a key it keeps, the token is bound to that key, and the authorization scheme becomes Authorization: DPoP - a resource server "MUST reject a DPoP-bound access token received as a bearer token". Built for SPAs and native apps; theDPoP page is the deep dive - the proof JWT anatomy, the cnf/jkt binding, the nonce, and which refresh tokens get bound.