Learn what bearer tokens are, how they work in OAuth 2.0 and JWT, the difference from access tokens, and best practices.
Behind almost every modern app login or API request sits a quiet workhorse: the bearer token. You may not notice it, but it’s there each time you connect services, sign in, or fetch data from the cloud.
This guide walks through what bearer tokens do, why they matter, and how to handle them safely.
A bearer token is a piece of data, usually a string of characters, that proves the holder is allowed to access a resource. The important thing is that whoever bears the token can use it, without needing to provide extra proof.
Think about an airline boarding pass. Once you have it in hand, you can pass through security and board the plane. No one asks you to show your ID again if the pass is valid. In the same way, a bearer token lets your application “board the API” without re-checking your identity each time.
For example, after you log into Spotify on your phone, you don’t need to enter your password every time you play a song. Instead, the app stores a bearer token that tells Spotify’s servers, “this request comes from an authorized user.”
The flow of bearer tokens can be broken into a few steps:
User logs in
Suppose you log in to a banking app with your username and password.
Identity provider issues a token
Once verified, the authentication server sends back a bearer token. This could look like:
Client uses the token
Every time you tap “Check Balance” or “Transfer Money,” the app includes the token in the HTTP request:
API validates it
The server checks if the token is still valid, not expired, and includes the right permissions (like read:balance or write:transfer).
Access granted
If all checks pass, the server responds with the requested information.
This model is widely used in services like GitHub APIs, where developers authenticate with a bearer token instead of repeatedly entering credentials.
Bearer tokens rose to prominence because they solved common problems in web security. Unlike server-based sessions, they do not require storing data for every logged-in user. Instead, the token itself contains enough information for the server to validate requests.
For instance, in a microservices architecture, where dozens of services talk to each other, maintaining central session storage would be complex and inefficient. With bearer tokens, each service can independently validate requests, keeping the system lightweight and scalable.
A concrete example: Slack’s APIs rely heavily on bearer tokens. When you build a Slack bot, you get a token that allows your bot to call Slack’s endpoints without maintaining a session for every user.
Many bearer tokens are implemented as JWTs (JSON Web Tokens). These tokens are encoded strings that include information about the user and their permissions.
Let’s decode a sample JWT:
Here’s what it means:
sub: The subject, or unique ID of the user.name: The user’s name.iat: Issued at timestamp.exp: Expiration time (when the token becomes invalid).scope: The permissions, in this case allowing the app to both read and write messages.In practice, if Jane’s token only had the scope read:messages, the app would be able to fetch her messages but not send a new one on her behalf.
It’s easy to mix up bearer tokens and access tokens, because the two terms often appear together. In fact, they’re related but not identical.
An access token is a credential that represents a user’s authorization to access a resource. It carries information like:
Think of it like a permission slip signed by the school principal. It tells the teacher (the API) that you’re allowed to go on the field trip (access the resource).
For example, when you log in to a cloud storage service, the system issues an access token with the scope read:files. That token tells the storage API: “This user can read files, but not delete them.”
A bearer token is a type of access token. The word bearer describes how the token is used: whoever presents it can “bear” it to access resources, with no further proof of identity required.
In other words:
There are other token types, like holder-of-key tokens, that require the client to prove possession of a cryptographic key in addition to the token. Bearer tokens skip that extra step, which makes them simpler but also riskier if stolen.
<token> header.This means when you see “access token” in OAuth tutorials, it is almost always a bearer token unless specified otherwise.
To make the picture clearer, let’s look at how bearer tokens compare with other common token types:
Bearer tokens and access tokens are not opposing concepts — they are related in scope:
Validating a bearer token is what stands between your API and unauthorized access. If your tokens are JWTs, validation happens locally and quickly. The API can check the token without calling the issuer every time.
Use this as a runbook when wiring an API gateway or a middleware.
Signature
Verify the signature using the algorithm in the header (for example RS256). Fetch the issuer’s JWKS endpoint, pick the key that matches the kid, and cache it.
Issuer (iss)
Match the token’s iss to your trusted issuer URL, exactly and with the correct scheme.
Audience (aud)
Ensure the token was meant for your API. Compare to your API identifier like https://api.example.com or a logical audience string.
Expiration (exp) and Not-Before (nbf)
Reject expired tokens. Respect nbf so a token cannot be used before its start time. Allow small clock skew, typically 30 to 60 seconds.
Issued-At (iat)
Useful for debugging and for rejecting very old tokens in strict setups.
Token type
Confirm it is an access token. Some providers include typ: "at+jwt" or similar. Do not accept ID tokens for API access.
Scopes / permissions
Read scope or provider-specific claims (for example permissions, roles). Enforce least privilege at each endpoint.
Subject (sub)
The stable user or client ID. Use it to associate resources and for auditing.
Replay and revocation (optional but wise)
For sensitive endpoints, check a short-lived denylist of jti values, or validate an active session record. This helps after logout or suspected compromise.
Because bearer tokens are “whoever holds it can use it,” they must be treated like house keys. If someone steals your key, they can unlock your door until you change the lock.
Some common risks include:
Real-world breaches have occurred when developers accidentally committed bearer tokens to public GitHub repositories. Attackers can scan for these tokens and immediately exploit them to gain unauthorized access.
To use bearer tokens securely, it’s important to follow best practices. Let’s walk through them with examples:
Always use HTTPS
Imagine sending a token over plain HTTP on a public café Wi-Fi. Anyone sniffing the network could copy the token and log in as you.
Use short-lived access tokens
Most platforms issue tokens that expire within an hour. For example, Google’s OAuth tokens typically last one hour before requiring refresh.
Refresh tokens carefully
A refresh token can request new access tokens without requiring the user to log in again. But it should be stored securely (e.g., in an encrypted database on the server) rather than in client-side storage.
Scope tokens to minimum permissions
If your app only needs to read a user’s calendar, don’t request write:calendar. This minimizes damage if the token is compromised.
Revoke tokens when necessary
Many SaaS apps allow users to see active sessions and revoke them. GitHub, for example, lets you revoke personal access tokens at any time.
Monitor usage
Logging token usage can reveal suspicious activity. If the same token is suddenly used from London and New York within minutes, that’s a red flag.
It’s useful to compare bearer tokens with other popular approaches:
Cookies & Sessions
Traditional websites rely on server-stored sessions identified by a cookie. This works well for browser apps but is less efficient for APIs or mobile apps. For example, logging into Facebook on desktop primarily uses cookies, while its mobile APIs use tokens.
API Keys
An API key is a static string that authenticates the application, not the user. For instance, a weather app may use an API key to fetch data, but that key doesn’t tell the server which user is requesting the forecast. Bearer tokens can carry user-specific data, making them more versatile.
Mutual TLS (mTLS)
Some high-security systems use certificates on both client and server. While more secure, this setup is harder to deploy at scale. For most SaaS platforms, bearer tokens strike the right balance between usability and security.