An access token is a credential a client presents to prove it is allowed to do something — usually calling an API. Instead of sending a username and password with every request, the client authenticates once, receives a token, and then attaches that token to subsequent requests. The server checks the token instead of re-checking the password. That is the whole idea; everything else is format and plumbing.
Bearer authentication
The most common way to send a token is the Authorization header:
Authorization: Bearer <token>
"Bearer" means exactly what it sounds like: whoever bears the token gets the access. There is no signature to verify possession, no challenge-response — the string itself is the key. That is why token secrecy matters so much: anyone who copies a Bearer token can impersonate its holder until it expires or is revoked. Our security practices guide covers how to keep real ones safe.
Where tokens come from: OAuth 2.0
Most modern tokens are issued through OAuth 2.0, an authorization framework with a few standard flows:
- Authorization code flow — the classic "log in with" flow. The user approves access in a browser, the app receives a one-time code, and exchanges it for an access token (plus usually a refresh token).
- Client credentials flow — for server-to-server calls with no user involved. The app authenticates with its own client ID and secret and gets a token directly.
- Refresh flow — access tokens are deliberately short-lived (minutes to hours). A longer-lived refresh token is used to mint new access tokens without bothering the user again.
The access token itself is often a JWT (JSON Web Token): three base64url-encoded parts — header, payload, signature — separated by dots. The payload carries claims like who the token is for (sub), when it was issued (iat) and when it expires (exp). The signature lets the server verify the token was really issued by it, without a database lookup.
API keys vs access tokens
People use the terms loosely, but they usually mean different things:
| API key | Access token | |
|---|---|---|
| Lifetime | Long-lived (months/years) | Short-lived (minutes/hours) |
| Sent as | Custom header (e.g. x-api-key) | Authorization: Bearer |
| Identifies | Usually a project or app | Usually a user + scopes |
| Revocation | Manual, via dashboard | Expiry + refresh, or revocation list |
| Example shape | sk-... random string | JWT or opaque random string |
Many real systems use both: an API key identifies the application, and an OAuth access token identifies the user and their permissions.
Why mock tokens exist
When you are building the code that handles tokens — middleware that reads the Authorization header, a client that refreshes expiring tokens, documentation with curl examples — you need realistic-looking tokens long before you have real ones. That is what TokenTonic generates: strings shaped like API keys, Bearer tokens and JWTs, with proper prefixes and entropy, that grant access to nothing. They let you test the plumbing without touching production credentials.
Key takeaway: a Bearer token is a password that travels in every request. Treat real ones like passwords — short-lived, secret, and never logged. Treat mock ones as what they are: convenient test data. The formats guide breaks down the shapes tokens take in the wild.
Related guides
- Access token formats — prefixes, encodings and JWT anatomy.
- Token use cases — where mock tokens earn their keep.