How is a bearer token transmitted on an HTTP request per RFC 6750, and what does the word 'bearer' actually mean about how the server treats it?

## The wire format RFC 6750 defines the `Bearer` authentication scheme within the HTTP authentication framework. A request carries: ``` Authorization: Bearer mF_9.B5f-4.1JqM ``` Details that come up in interviews: - **The scheme name is case-insensitive** (`Bearer`, `bearer`, `BEARER` are all valid to parse), but conventionally written `Bearer`. The **token value is case-sensitive**. - Exactly one space separates scheme and token, and the token is a `b64token`: characters `A–Z a–z 0–9 - . _ ~ + /` with optional trailing `=`. That charset is why base64url-encoded JWTs fit without escaping. - The token is **opaque to the client**. Even when it happens to be a JWT the client can decode, RFC 6750 treats it as a bare string to relay; only the issuer and the resource server are entitled to interpret it. - **One credential per request.** Sending a token in two places at once (say header and query parameter) is a malformed request, and the server should reject it rather than pick a winner. ## What "bearer" means A bearer credential is honoured on the basis of possession alone. Compare it to the alternatives: - A **Basic** credential is also possession-based, but the secret is a long-lived password the user knows. - A **proof-of-possession** credential (mutual TLS per RFC 8705, or DPoP per RFC 9449) requires the client to demonstrate control of a private key on each request, so a copied token is useless without the key. - A **bearer** token requires nothing beyond presenting the string. So the entire security of the scheme rests on the token never being seen by anyone else, and on it not being valuable for long. There is no request signature, no channel binding, no client identity check — a proxy, a log file or an attacker who obtains the string is, from the server's point of view, the client. ## What the server does with it Validation is out of scope for the carriage spec, but the two shapes are worth knowing. If the token is self-contained (typically a signed JWT), the resource server verifies the signature and checks claims such as expiry, issuer and audience locally — fast, but revocation before expiry needs extra machinery. If the token is a random opaque handle, the server looks it up, usually by calling the issuer's introspection endpoint or reading shared state — slower per request, but revocation is immediate. Either way the client's behaviour is identical, which is the point of an opaque credential. ## The other two carriage methods RFC 6750 defines three ways to send a bearer token: the `Authorization` header, a `access_token` form-encoded body parameter (only for `application/x-www-form-urlencoded` bodies), and an `access_token` URI query parameter. Only the header must be supported by servers. The body method exists for constrained clients that cannot set headers; the URI method exists for cases where neither is possible and is explicitly discouraged, because URLs leak into logs, browser history, `Referer` headers and shared links. Modern practice — and later OAuth security guidance — is header-only. ## Required companions Because possession is everything, RFC 6750 attaches conditions to using it at all: - **TLS is mandatory**, with certificate validation. A bearer token over plaintext is a password over plaintext, except it may also unlock more than one service. - **Responses to authenticated requests should carry `Cache-Control: no-store`**, so shared caches do not retain private data or, worse, a token echoed in a body. - **Tokens should be short-lived and audience-restricted**, so a leak is bounded in time and in which service accepts it. - **Never log the `Authorization` header**, and scrub it in tracing, error reporting and HAR captures. ## Common client mistakes - Writing `Authorization: <token>` with no scheme, or `Authorization: Bearer: <token>` with a stray colon — both are malformed and produce confusing 401s. - Sending `Bearer undefined` or `Bearer null` when the token store is empty, instead of omitting the header, which turns a clean anonymous request into an invalid-token error. - Attaching the token to requests for third-party origins because the HTTP client was configured with a global default header. Bearer tokens must be scoped to the audience that issued them. - Sending both a session cookie and a bearer token and assuming the server prefers one; it may honour the other, which has real CSRF implications. ## The sentence to say in an interview "A bearer token is carried in the `Authorization: Bearer <token>` header, is opaque to the client, and is honoured purely on possession — so it is only as safe as TLS, short lifetimes, narrow audience and disciplined logging make it."