Bearer Token Authentication

What 'bearer' means

A bearer token grants access to whoever presents — or bears — it, in much the same way that cash is spendable by whoever holds the note. There is no additional proof of identity required beyond possession of the token itself. This simplicity is exactly why bearer tokens are so widespread across APIs: they are easy to issue, easy to send, and easy to validate.

The same simplicity, however, means that a stolen token is immediately and fully usable by whoever takes it, with no further hurdle to clear. There is no second factor protecting it once it has left your control. The Merion API accepts bearer tokens on its REST endpoints, so guarding those tokens carefully is the single most important habit for any caller to develop, and the rest of this guide follows from that one fact.

Presenting the token

Clients send a bearer token in the HTTP Authorization header, prefixed with the scheme name that tells the server how to interpret it. Every protected request carries the token in this header; the server reads it, validates it, and serves the response if the token checks out. The pattern is uniform across virtually every modern API, which is part of what makes bearer tokens so convenient to work with.

Authorization: Bearer <access-token>

Resist any temptation to place tokens in the URL query string instead, however convenient it might seem for a quick test. URLs are routinely written to server logs, saved in browser history, and forwarded in referrer headers, any of which would leak the token to somewhere you did not intend. The header is both the correct location and the materially safer one.

The leak risk

Because possession alone equals access, a leaked bearer token is a live, working credential right up until the moment it expires or is explicitly revoked. There is no grace period in which it is merely "compromised but harmless"; it is simply usable. That is what makes a leak more serious than it might first appear, and why short lifetimes matter so much.

The common leak vectors are mostly mundane rather than exotic: logging the full Authorization header, embedding tokens in URLs, and storing them in insecure browser storage where any injected script can read them. Short token lifetimes blunt the impact of all of these by ensuring a leaked token soon stops working, which is one of the central reasons access tokens are issued with such brief lifetimes — see Access Tokens vs Refresh Tokens for the trade-offs involved.

Handling them safely

Always send bearer tokens over TLS, so they cannot be sniffed from the network in transit by anyone observing the connection. Keep them out of application logs and analytics pipelines, where they would otherwise sit in plain text for anyone with log access to find. Store them in memory or in secure platform storage rather than plain files, and revoke them promptly the moment a session ends.

For higher-assurance scenarios where even a stolen token must be made useless, sender-constrained approaches such as mutual TLS bind a token to a specific client so that possession alone is no longer enough. That technique directly addresses the core weakness of bearer tokens; see Mutual TLS Overview for how it works and when the additional complexity is worth taking on.