What Is a Bearer Token? How It Works and Best Practices

TL;DR:

What is a bearer token?

A bearer token is an access token that grants API access to whoever presents it. The client sends it in the HTTP header Authorization: Bearer <token>, and the API checks that the token is valid, unexpired and scoped for the request.

No extra proof of identity is needed, so a stolen bearer token works for the thief too.

That's why bearer tokens should be short-lived, narrowly scoped, sent only over HTTPS, and easy to revoke.

‍A partner’s developer pastes a cURL command into a support ticket. It includes a full Authorization header. The ticket gets copied into a chat thread, then into a wiki page. Anyone who reads that page now holds a working bearer token for your production API, because a bearer token doesn’t care who sends it. It only cares that it’s valid.

That’s the trade-off at the heart of token based authentication. Bearer tokens are simple, fast and supported everywhere. They’re also as dangerous as cash if they leak. GitGuardian’s State of Secrets Sprawl 2026 report counted 28.6 million new secrets in public GitHub commits in 2025, up 34%. Worse, 64% of valid secrets found in 2022 were still active four years later. Nobody had revoked them.

This guide explains what is a bearer token, how bearer authentication works step by step, how it compares with an API key, and the practices that keep a leaked token from turning into a breach.

What is a bearer token?

A bearer token is a credential that grants access to whoever holds (“bears”) it. The API doesn’t ask the caller to prove they are the rightful owner. If the token is valid, the request goes through.

In practice, almost every OAuth 2.0 access token you’ve used is a bearer token. When an app signs you in with Google, or a partner’s server calls your orders API, the credential on each request is usually a bearer token.

What does “bearer” mean?

“Bearer” works the way it does on a concert ticket or a banknote. The venue doesn’t check your ID. It checks that the ticket is real. Whoever bears the ticket gets in.

That design makes bearer tokens easy to use. Any client that can set an HTTP header can call your API. It also explains the main risk, which we’ll come back to: a copied ticket works as well as the original.

What does a bearer token look like?

A bearer token is a string. It comes in two common formats:

• Opaque token: a random string such as 8f2c1e9a7b.... It means nothing on its own. The API asks the authorization server what it stands for, a process called token introspection.
• JSON Web Token (JWT): three Base64URL-encoded parts joined by dots: header.payload.signature. The payload carries claims such as who the token is for, when it expires and what it may do. The API can verify it locally by checking the signature.

Here’s what a request with a bearer token looks like on the wire:

GET /v1/orders/8812 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ims3In0.eyJzdWIiOiJhcHBfcGFydG5lcl8yMjEiLCJzY29wZSI6Im9yZGVyczpyZWFkIiwiZXhwIjoxNzY3MjI1NjAwfQ.c2lnbmF0dXJl

A bearer token and a JWT aren’t the same thing. “Bearer” describes how a token is used: whoever holds it gets in. “JWT” describes what a token is made of: a signed JSON object. Most JWT access tokens are sent as bearer tokens, but a bearer token can also be opaque. We cover the token formats in more depth in OAuth 2.0 vs JWT: what’s the difference.

How does bearer authentication work?

Bearer authentication is a two-part exchange. First, the client gets a token from an authorization server. Then it sends that token in the Authorization header of every API call, and the API (usually its gateway) validates it before answering.

Here’s the flow step by step, using a partner app that calls your API with no user present (the OAuth 2.0 client credentials flow):

1. The client proves who it is. The partner app sends its client ID and secret to the authorization server’s token endpoint.
2. The authorization server issues a token. It checks the credentials and returns an access token with an expiry time and a list of scopes.
3. The client calls the API. It adds Authorization: Bearer <token> to the request.
4. The gateway validates the token. It checks the signature (or asks the authorization server), the expiry, the issuer, the audience and the scopes.
5. The API responds. A valid token gets the data. An invalid or under-scoped one gets 401 or 403.

Steps 1 and 2 look like this:

curl -X POST https://auth.example.com/oauth2/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  -d "scope=orders:read"

{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims3In0...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "orders:read"
}

And step 3, in cURL and Python:

curl https://api.example.com/v1/orders/8812 \
  -H "Authorization: Bearer $ACCESS_TOKEN"

import os
import requests

token = os.environ["ACCESS_TOKEN"]  # never hard-code tokens
resp = requests.get(
    "https://api.example.com/v1/orders/8812",
    headers={"Authorization": f"Bearer {token}"},
    timeout=10,
)
resp.raise_for_status()
print(resp.json())

Notice expires_in: 900. This token dies after 15 minutes. When it does, the client asks for a new one. For apps acting on behalf of a signed-in user, a longer-lived refresh token handles that renewal so the user doesn’t have to log in again.

Where can a bearer token go in a request?

RFC 6750 allows three places to send a bearer token. Only one of them is a good idea.

Two more rules from the standard: a client must never send the same token two ways in one request, and an API must support the header method.

If you document your API with OpenAPI, declare bearer authentication once as a security scheme. Your developer portal and generated SDKs will then show the right header automatically.

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT   # optional, for documentation only
security:
  - bearerAuth: []

What happens when a bearer token is rejected?

When a bearer token fails, the API should say why in a standard way. RFC 6750 defines three error codes, each sent in a WWW-Authenticate response header. Clients use these to decide whether to get a new token, ask for more scopes, or fix the request.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="orders-api",
  error="invalid_token",
  error_description="The access token expired"

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer realm="orders-api",
  error="insufficient_scope",
  scope="orders:write"

The split between 401 and 403 matters. A 401 means “I don’t know who you are.” A 403 means “I know who you are, and the answer is no.” We explain the difference fully in authentication vs authorization.

Bearer token vs API key: what’s the difference?

An API key is a long-lived secret that identifies an app. A bearer token is a short-lived credential that carries who the caller is and what it may do. Both are sent with each request, and both work for whoever holds them. The difference is how long they live and how much they say.

So which should you use? This is the core of the bearer token vs API key decision:

• Use an API key when the caller is a known server, the data is low risk, and you need the simplest possible onboarding.
• Use bearer tokens when callers act on behalf of users, when different callers need different permissions, or when a leaked credential must expire on its own.

Many API programs use both. A partner gets an API key to identify their app, then exchanges client credentials for short-lived bearer tokens to call sensitive endpoints. For a deeper comparison, see OAuth vs API keys.

Why are bearer tokens a security risk?

A bearer token is risky because possession is the only check. If an attacker copies it, the API can’t tell them apart from the real client until the token expires or someone revokes it. Every bearer token risk comes back to this one fact.

Credentials are the most common way in. The Verizon 2025 Data Breach Investigations Report found that credential abuse was the leading initial access vector, at 22% of breaches. In Salt Security’s 2025 State of API Security report, 29% of organizations named API authentication weaknesses as a problem. And OWASP ranks Broken Authentication as API2:2023, the second most critical API risk.

Here’s how bearer tokens actually leak in API programs:

• Tokens in URLs. A token in ?access_token= lands in access logs, browser history, analytics tools and Referer headers.
• Tokens in code and tickets. Developers paste tokens into scripts, Postman collections, support tickets and chat. Those copies outlive the person who made them.
• Long-lived tokens. A token that lasts 30 days gives an attacker 30 days. Some teams set long expiries to stop integrations breaking, and trade security for convenience.
• Over-broad scopes. One token that reaches every API turns a small leak into full access. This is the most common gap we see when partners are onboarded by hand.
• No way to pull a token back. Self-contained JWTs stay valid until they expire. If you can’t revoke them, a leaked token keeps working.
• Tokens shared with AI agents. An agent given a developer’s personal token inherits all of that developer’s access, with no record of what the agent did.

What are the best practices for using bearer tokens?

Keep bearer tokens short-lived, narrowly scoped, sent only over HTTPS, and checked on every request. Assume some tokens will leak, and design so a leaked token is worth as little as possible. These 10 practices follow the OAuth 2.0 Security Best Current Practice (RFC 9700) and what we see work in production API programs.

1. Send tokens only over HTTPS: TLS stops anyone on the network from reading the header. Reject plain HTTP outright rather than redirecting it.
2. Use the Authorization header only: Turn off query string and form body support at the gateway so tokens can’t end up in URLs.
3. Set short token expiration times: RFC 6750 recommends one hour or less, and 5 to 30 minutes is common for sensitive APIs. Use refresh tokens, or the client credentials flow, to get new ones.
4. Scope every token to the least it needs: Issue orders:read instead of orders:*. Set an audience (aud) so a token for one API can’t be replayed against another.
5. Validate every claim on every request: Check the signature, exp, nbf, iss and aud, and the scope. Reject alg: none and pin the algorithms you accept.
6. Make tokens revocable: Keep access tokens short, and support token revocation (RFC 7009) for refresh tokens and opaque tokens. When a partner contract ends, revoke the app’s credentials in one step.
7. Never log full tokens: Mask the Authorization header in gateway, application and APM logs. Log a token ID (jti) instead.
8. Store tokens like secrets: Use a secrets manager or the OS keychain on servers. In browsers, prefer HttpOnly, Secure cookies or an in-memory store over localStorage.
9. Bind high-value tokens to the client: Use sender-constrained tokens (DPoP or mutual TLS) for payments, health data and partner APIs. More on this below.
10. Rotate client secrets and monitor use: Rotate the secrets that mint tokens on a schedule, alert on tokens used from new IPs or at odd volumes, and review who holds access every quarter. Our guide to rotating API keys automatically covers the rotation side.

How do you make a stolen bearer token useless?

Use sender-constrained tokens, which bind the token to a key only the real client holds. The API then checks both the token and proof of that key. A thief who copies the token but not the key gets a 401.

There are two standard ways to do this:

• Mutual TLS (RFC 8705): the token is tied to the client’s TLS certificate. It’s a strong fit for server-to-server and regulated traffic. See our explainer on what mTLS is and how it works.
• DPoP (RFC 9449): the client signs a small proof with its private key on every request and sends it in a DPoP header. It works where mTLS is hard, such as browser and mobile apps.

GET /v1/orders/8812 HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGciOiJSUzI1NiIsImtpZCI6Ims3In0...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2In0...

RFC 9700 recommends sender-constrained tokens as the main defense against token replay. You don’t need them everywhere. Start with the APIs where a leak would hurt most.

Should AI agents use bearer tokens?

Yes, but each agent should get its own short-lived, narrowly scoped token, never a human’s. AI agents calling APIs through the Model Context Protocol (MCP) use OAuth 2.1 bearer tokens. The MCP authorization spec requires those tokens in the Authorization header, bans them from query strings, and says servers must check that each token was issued for them (its audience). An MCP server must also never pass a client’s token straight through to a downstream API.

The risk with agents is scale. An agent can make thousands of calls a minute, so an over-scoped token does damage fast. Give each agent its own client identity, scope its token to the tools it needs, and log every call against that identity. Our guide to securing MCP endpoints walks through the setup.

How does an API gateway validate bearer tokens?

An API gateway validates bearer tokens before any request reaches your backend. It reads the Authorization header, verifies the token, checks its claims against the route, and rejects anything that fails. Doing this once at the gateway means every service gets the same rules.

Here’s the check order a well-configured gateway follows:

1. Header present, scheme is "Bearer", token is well formed → else 401 invalid_request
2. Signature valid against the issuer's JWKS (or introspection says active) → else 401 invalid_token
3. exp is in the future, nbf is in the past (allow small clock skew) → else 401 invalid_token
4. iss is a trusted issuer, aud matches this API → else 401 invalid_token
5. Token not on the revocation list → else 401 invalid_token
6. Scope covers this route and method → else 403 insufficient_scope
7. Rate limit for this client not exceeded → else 429

JWTs vs opaque tokens at the gateway. A gateway can verify a JWT locally using the issuer’s public keys, which is fast but means revocation only takes effect at expiry. For an opaque token, the gateway calls the authorization server’s introspection endpoint (RFC 7662), which reflects revocation right away but adds a network hop. Many teams use JWTs with short expiries for most traffic and introspection for high-risk routes.

The hard part isn’t one gateway. It’s five. Large organizations often run Kong, Apigee, AWS API Gateway and Azure API Management side by side, each with its own token settings. One gateway checks aud, another doesn’t. One accepts 24-hour tokens, another 15 minutes. Those gaps are where leaked tokens get through.

This is where an API management layer earns its place. The DigitalAPI API Gateway supports OAuth, OIDC, Keycloak, Okta and mTLS, so the same token policy applies across every gateway you run. Teams using the DigitalAPI API Developer Portal replace credentials sent by email with self-service requests, built-in OAuth 2.0 token generation, and one-click revocation when a contract ends or a key leaks. For AI traffic, the MCP Gateway issues OAuth 2.1, API key and mTLS credentials per agent, with scopes per tool and an audit trail for every call.

See how DigitalAPI keeps every bearer token scoped, short-lived and revocable across your gateways → Book a Demo

Should you use bearer tokens for your API?

Bearer tokens are the right default for most modern APIs, as long as you control their lifetime and scope. Use the checklist below to decide.

Key takeaways

• A bearer token grants access to whoever holds it, with no extra proof of identity.
• Send it only in the Authorization: Bearer header, only over HTTPS.
• Bearer tokens beat API keys when you need expiry, scopes or user context. API keys win on simplicity.
• Most leaks come from logs, URLs, code and tickets. Short expiry and narrow scopes limit the damage.
• For high-value APIs, use sender-constrained tokens (DPoP or mTLS) so a stolen token can’t be replayed.
• Enforce one token policy at the gateway layer, across every gateway, for apps and AI agents alike.

Frequently asked questions

1. What is a bearer token in simple terms?

A bearer token is a digital pass for an API. Whoever holds the pass can use it, the way anyone holding a concert ticket can get in. The client sends it in the Authorization: Bearer header, and the API lets the request through if the token is valid and covers the action.

2. Is a bearer token the same as an access token?

Not exactly. An access token is any credential that grants access to an API. A bearer token is an access token used under the bearer rule: possession alone is enough. Most OAuth 2.0 access tokens are bearer tokens, but sender-constrained access tokens (DPoP or mTLS) are not, because they also require proof of a key.

3. Is a bearer token the same as a JWT?

No. “Bearer” describes how a token is used: whoever holds it gets access. “JWT” describes a token format: a signed JSON object with claims. A JWT is often sent as a bearer token, but a bearer token can also be an opaque random string with no readable content.

4. How long should a bearer token last?

Most access tokens should expire in an hour or less, as RFC 6750 recommends, and 5 to 30 minutes for sensitive APIs. Shorter lifetimes limit how long a stolen token works. Clients get new tokens with a refresh token or by repeating the client credentials flow. API keys and refresh tokens last longer, so they need stronger storage and rotation.

5. Where should a bearer token be stored?

On servers, store bearer tokens in memory or a secrets manager, never in source code or config files checked into Git. In browsers, prefer HttpOnly, Secure, SameSite cookies or in-memory storage over localStorage, which any script on the page can read. On mobile, use the platform keychain or keystore.

6. How do I send a bearer token in Postman or cURL?

In cURL, add the header with -H "Authorization: Bearer YOUR_TOKEN". In Postman, open the request’s Authorization tab, choose “Bearer Token”, and paste the token, ideally from an environment variable. Both tools then send Authorization: Bearer <token> with the request.

7. Can a bearer token be revoked?

Yes, but how depends on the format. Opaque tokens can be revoked at the authorization server, and the API sees the change on its next introspection call. Self-contained JWTs stay valid until they expire unless the API also checks a revocation list. That’s why short expiry matters most for JWTs.

8. Why is my API returning 401 with a bearer token?

A 401 means the API couldn’t authenticate the token. The usual causes are an expired token, a missing Bearer prefix or extra space, a token issued for a different API (wrong aud), or a signature the API can’t verify. Check the WWW-Authenticate header in the response: its error_description usually names the cause.

Conclusion

A bearer token is the simplest way to grant API access: hold the token, make the call. That simplicity is also its weakness, because a copied token works for anyone. The fix isn’t to abandon bearer tokens. It’s to make every token short-lived, narrowly scoped, sent only in the Authorization header over HTTPS, validated at the gateway on every request, and easy to revoke.

Start with the basics this week. Turn off tokens in URLs, mask the Authorization header in your logs, and check which of your tokens last longer than an hour. Then look at who holds access to what. That’s usually where the real gaps are.

How safely do you grant API access to partners and AI agents? Get your free readiness score: Check Your API Access Readiness

Prefer a walkthrough? Book a Demo