Category: Tokens & Sessions

Bearer Token

Also known as: Bearer Authentication Token

Simply put

A bearer token is a security token that grants access to whoever holds it, meaning any party in possession of the token can use it to reach a protected resource without providing any additional proof of identity. Because possession alone is sufficient, a bearer token functions somewhat like cash: whoever holds it can spend it. This makes protecting the token in transit and at rest especially important.

Formal definition

A bearer token is an access token whose defining property is that any party in possession of it may use it to access protected resources, with no requirement to demonstrate proof-of-possession or additional identity beyond presenting the token itself (per RFC 6750). In the OAuth 2.0 context, RFC 6750 specifies how bearer tokens are conveyed in HTTP requests to access protected resources, most commonly via the HTTP Authorization header using the 'Bearer' authentication scheme. The bearer token is typically an access token used at the authorization stage to reach a resource; it should not be conflated with an ID token, which conveys authentication information. Bearer tokens may be opaque strings (requiring introspection or validation by the issuer) or self-contained (such as a JWT that a resource server can validate locally), depending on the deployment. Note that a bearer token being signed does not mean it is encrypted, and its bearer nature means interception of the token is generally sufficient to impersonate the legitimate holder; proof-of-possession mechanisms, out of scope for the base bearer model described here, are needed to mitigate that risk.

Why it matters

The defining property of a bearer token, that possession alone grants access, is also its primary security weakness. Because a resource server accepts the token from whoever presents it, without requiring the holder to prove identity or ownership, an intercepted or leaked bearer token can typically be replayed by an attacker to impersonate the legitimate holder. This is why the analogy to cash is apt: there is no built-in binding between the token and the party entitled to use it. For teams operating OAuth 2.0-protected resources, this shapes decisions about transport security, token lifetime, and storage.

As a result, protecting bearer tokens in transit and at rest is essential. Per RFC 6750, bearer tokens are conveyed in HTTP requests, most commonly in the Authorization header, and their exposure through logs, referrer headers, browser storage, or unencrypted channels is a common source of risk. Shorter token lifetimes and tight scoping can reduce the window and blast radius of a compromised token, though the specific mitigations depend on the deployment and standard profile in use.

It is worth noting that a bearer token being signed does not mean it is encrypted; a signed JWT can still be read by anyone who intercepts it, and its bearer nature means interception is generally sufficient to use it. Proof-of-possession mechanisms, which bind a token to a client key so that mere possession is not enough, exist to mitigate this risk, but they fall outside the base bearer model and must be adopted deliberately.

Who it's relevant to

IAM engineers and API developers

Engineers implementing OAuth 2.0-protected resources need to understand that bearer tokens grant access on possession alone. This affects how they transmit tokens (typically via the Authorization header per RFC 6750), whether they choose opaque or self-contained token formats, and how they perform validation, via issuer introspection for opaque tokens or local signature and claim checks for JWTs.

Security architects

Architects weighing token strategy must account for the bearer model's core tradeoff: simplicity of use versus the risk that an intercepted token can be replayed. Where that risk is unacceptable, they may evaluate proof-of-possession mechanisms, which bind a token to a client and fall outside the base bearer model described here, alongside transport protection, token lifetimes, and scoping.

System administrators and operations teams

Teams responsible for running services that accept bearer tokens should ensure tokens are protected in transit and at rest and are not exposed through logs or insecure storage. Because a signed token is not necessarily encrypted, its contents may be readable if intercepted, reinforcing the need for careful handling of tokens in operational environments.

Inside Bearer Token

Token value

The opaque or self-contained string presented by the client to gain access. In the case of a self-contained bearer token such as a JWT, the value itself encodes claims; in the case of an opaque bearer token, the value is a reference that must be validated against the issuing or introspection endpoint.

Presentation mechanism

Bearer tokens are typically presented in the HTTP Authorization header using the 'Bearer' scheme (Authorization: Bearer <token>), as described in the OAuth 2.0 bearer token usage specification. Other transmission methods exist depending on configuration but the Authorization header is the most common.

Scope and grant context

In OAuth 2.0, a bearer access token typically represents a delegated authorization granted to a client, often carrying or referencing scopes that determine what resources the token may access. Note that scope governs authorization, not the authentication of the end user.

Validation surface

For self-contained bearer tokens, resource servers validate signature, issuer, audience, and expiry claims locally; for opaque bearer tokens, validation is typically performed via an introspection endpoint. A signed token proves integrity and origin but is not necessarily encrypted, so its contents may be readable unless additional protection is applied.

Common questions

Answers to the questions practitioners most commonly ask about Bearer Token.

Does a bearer token identify or authenticate the client presenting it?

No. A bearer token, by definition, is honored based solely on possession, any party that holds it can use it. The token does not authenticate the presenter as a specific client; whoever bears the token is granted the associated access. This is the defining characteristic (and primary risk) of the bearer model, and it is what distinguishes bearer tokens from sender-constrained or proof-of-possession tokens, where the presenter must additionally demonstrate control of a key bound to the token.

Is a bearer token the same as an OAuth 2.0 access token?

Not exactly. "Bearer" refers to how a token is used and presented, not to what the token represents. In OAuth 2.0, access tokens are commonly issued and used as bearer tokens, but access tokens can also be sender-constrained rather than bearer. Conversely, other token types (for example, certain refresh tokens depending on configuration) may be presented in a bearer fashion. Bearer describes a presentation and trust model; access token describes a role in the authorization framework. Treat the two terms as related but not synonymous.

How is a bearer token typically transmitted in an HTTP request?

In most OAuth 2.0 deployments, a bearer token is sent in the HTTP Authorization header using the Bearer scheme (for example, Authorization: Bearer <token>). Depending on configuration, some implementations also accept the token in a form-encoded body parameter or query parameter, though query-parameter transmission is generally discouraged because tokens can leak through logs, referrer headers, and browser history. The exact accepted methods vary by resource server and profile.

How should a resource server validate a bearer token?

Validation depends on whether the token is self-contained or opaque. For a self-contained token such as a signed JWT, the resource server typically verifies the signature, checks issuer and audience claims, confirms expiration and any not-before constraints, and evaluates scope or other claims relevant to authorization, noting that a signed token is not necessarily encrypted, so its contents may be readable. For an opaque token, the resource server generally calls an introspection endpoint or otherwise consults the authorization server to determine validity and associated metadata. Specific checks vary by profile and deployment.

What controls help mitigate the risk that a stolen bearer token can be replayed?

Because possession alone grants access, mitigations typically focus on limiting exposure and lifetime. Common measures include transmitting tokens only over TLS, keeping access-token lifetimes short and relying on refresh tokens for renewal, scoping tokens narrowly, and avoiding placement of tokens in URLs or logs. Where stronger assurance is required, some deployments move away from the pure bearer model toward sender-constrained or proof-of-possession approaches. The appropriate combination depends on threat model and supported standards.

Where should bearer tokens be stored on the client side?

Storage choices are context-dependent and involve trade-offs rather than a single correct answer. For browser-based clients, developers weigh options such as in-memory storage versus web storage versus cookies, each with different exposure to cross-site scripting and cross-site request forgery, and the choice interacts with cookie flags and application architecture. For confidential clients running in trusted server environments, tokens are typically kept server-side and not exposed to the user agent. The suitable approach varies by client type, threat model, and deployment; evaluate the specific risks rather than applying a universal rule.

Common misconceptions

A bearer token proves the identity of the client presenting it.

By definition, a bearer token grants access to whoever holds ('bears') it, without requiring the holder to prove possession of a corresponding key. Anyone in possession of the token can typically use it, which is why proof-of-possession or sender-constrained token mechanisms exist as alternatives where stronger binding is required.

A bearer token being signed means its contents are protected from being read.

A signature provides integrity and authenticity, not confidentiality. A signed but unencrypted bearer token (such as a typical JWT) can have its claims decoded and read by anyone who intercepts it, so sensitive data should not be placed in it unless it is also encrypted.

Bearer tokens are an authentication method for users.

A bearer access token in OAuth 2.0 conveys delegated authorization to access resources, not user authentication. User authentication is handled by a separate layer such as OpenID Connect, which issues an ID token distinct from the access token.

Best practices

Always transmit bearer tokens over TLS and avoid exposing them in URLs, logs, or referrer headers, since anyone who obtains the token can typically use it.

Keep bearer token lifetimes short and rely on refresh tokens or re-issuance rather than long-lived access tokens to limit the window of misuse if a token is leaked.

For resource servers validating self-contained bearer tokens, verify signature, issuer, audience, and expiry claims; for opaque bearer tokens, validate via the introspection endpoint rather than trusting the token blindly.

Do not place sensitive data in an unencrypted bearer token, since signing provides integrity but not confidentiality and the claims may be readable.

Where stronger assurance is needed, consider sender-constrained or proof-of-possession tokens instead of plain bearer tokens to reduce the risk of token theft and replay, depending on what your standard profile and vendor support.

Scope bearer access tokens to the minimum required permissions and audience so that a compromised token grants the least possible access.