A bearer token is an access token that works by possession: whoever holds it can present it to access the resources it authorizes, without proving possession of a separate cryptographic key. Send it to an HTTP API in the Authorization header as Bearer <token>, and protect it like a password. Bearer describes how the credential is presented—not whether it is a JWT or whether it proves a user’s identity.
What bearer token authentication means
RFC 6750 defines a bearer token as a security token that any party possessing it can use without demonstrating possession of a cryptographic key. The RFC puts it plainly: “Any party in possession of a bearer token (a ‘bearer’) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).” The IETF published RFC 6750 in October 2012.
In an OAuth-based system, an authorization server issues access tokens. A client presents an access token to a resource server, such as an API, which validates the token and enforces the authorization it grants. The bearer scheme alone does not establish that the current holder is the original user or client; it establishes only that the request presents the token.
OAuth is an authorization framework. Bearer is an HTTP authorization scheme commonly used to present an OAuth access token. They are related, but they are not interchangeable terms. For current OAuth security guidance, read RFC 9700, the IETF’s January 2025 OAuth 2.0 Security Best Current Practice, alongside the bearer-token protocol in RFC 6750 and the RFC 9700.
#1 Best Overall
How to send a bearer token in an API request
Use the Authorization header with the Bearer scheme. RFC 6750 requires resource servers to support this method and recommends that clients use it.
GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer <access-token>Replace <access-token> with the access token issued to your client. Send the request over HTTPS, not plain HTTP. Do not put the token in the URL: URLs can be retained in browser history, server logs, and other systems. RFC 6750 describes request-body transmission only for limited circumstances; the header is the standard choice for ordinary API requests.
Is a bearer token the same as a JWT?
No. “Bearer” describes the way a token is presented: possession is enough to use it. It does not define the token’s format or contents. A bearer token can be opaque, meaning the resource server resolves or looks it up, or it can be structured.
A JWT is one possible structured format. RFC 9068 defines a profile for JWT-formatted OAuth access tokens; JWT formatting is not required for bearer authentication. Using a JWT is not automatically a security upgrade. A resource server that accepts JWT access tokens must validate them according to the applicable profile and system design, including relevant issuer, audience, expiry, integrity, and claims checks.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to protect bearer tokens
RFC 6750 warns that bearer tokens need protection from disclosure in storage and transport. Treat an access token as a secret credential: anyone who obtains it may be able to replay it until it expires or is otherwise rejected.
- Use TLS and validate the server certificate. Protect token exchanges and API requests with HTTPS, and ensure the client validates the resource server’s certificate chain. Encryption without server authentication can leave a client vulnerable to sending a token to an impostor.
- Keep tokens out of URLs and logs. Query strings may be copied into history, analytics, referrer data, proxies, and server logs. As an implementation precaution, redact authorization headers and other credential-bearing data from application, proxy, and diagnostic logs.
- Limit where and what a token authorizes. Restrict the audience to the systems intended to accept the token, and grant only the scopes needed. Audience restriction narrows the set of systems that can accept a leaked token; scope restriction narrows the actions it can authorize.
- Choose a suitable lifetime. Short-lived access tokens reduce the window in which a stolen token can be reused. RFC 6750 recommends that token servers issue short-lived tokens and cites one hour or less as its recommendation; that is guidance in the 2012 specification, not a universal lifetime rule for every current system.
- Assess browser storage and CSRF together. RFC 6750 says bearer tokens must not be stored in cookies that can be sent in the clear and calls for CSRF precautions when tokens are stored in cookies. Cookie storage is not universally forbidden, but its attributes, transport protection, and the application’s CSRF defenses must fit the design.
For broader OAuth implementation decisions, consult OWASP’s living OAuth2 Cheat Sheet, accessed October 8, 2026.
Rank #4
When to consider sender-constrained tokens
Ordinary bearer tokens are straightforward: the client presents the token, and the resource server checks it. That simplicity also means a stolen token can be replayed by whoever has it. If replay after theft is a material threat, consider sender-constrained tokens, which require proof tied to client-held cryptographic material.
| Approach | What the client presents | Effect if a token is stolen | Operational trade-off |
|---|---|---|---|
| Ordinary bearer | The token; possession is sufficient. | A thief who obtains the token may replay it. | Simplest presentation model; no additional client key or certificate proof is required by the bearer scheme. |
| DPoP | The token plus proof tied to a client-held key. | Binding token use to the key can reduce the value of a stolen token without the corresponding key. | Requires key handling and proof support in both client and resource-server environment. |
| Mutual-TLS-bound token | The token in a mutually authenticated TLS connection using the bound client certificate. | Binding use to the certificate can reduce replay by a party lacking the corresponding certificate and private key. | Requires certificate provisioning, lifecycle management, and support across the relevant infrastructure. |
DPoP and mutual-TLS-bound tokens are discussed in RFC 9700 and OWASP’s OAuth2 Cheat Sheet. They add implementation and key-management work; choose them when their reduction in token replay risk justifies that complexity.
Best Value
- Used Book in Good Condition
What an API should return when a bearer token is invalid
RFC 6750 uses the WWW-Authenticate: Bearer challenge to communicate bearer authentication requirements. The response should distinguish a request that lacks usable authentication credentials from one whose credentials are valid but do not grant the requested action.
- No usable credentials: For a request with no usable authentication credentials, the resource server should return an authentication challenge. RFC 6750 illustrates
401 UnauthorizedwithWWW-Authenticate: Bearer realm="example". - Insufficient scope: When the credential is valid but lacks sufficient scope, the resource server may return
403 Forbiddenand may identify the required scope in the challenge.
Clients should treat a 401 as a signal that authentication is missing or unusable, rather than automatically retrying the same request with the same token. A 403 indicates that the presented authorization is insufficient for the requested resource or action.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
