API Tokens and Bearer Tokens Explained

An API token is a string a client sends to prove it is allowed to call an API. Instead of sending a username and password on every request, the client presents a token that the server recognizes. Done well, tokens are convenient and secure; done badly, they become long-lived passwords scattered across logs and repositories.

Bearer tokens

Most HTTP APIs use the bearer scheme. The client sends the token in the Authorization header:

Authorization: Bearer 9f86d081884c7d659a2feaa0c55ad015...

"Bearer" means exactly what it says: whoever holds the token can use it. There is no extra proof of identity, so a bearer token must be treated like a password — always sent over HTTPS and never exposed in URLs, logs, or client-side code that an attacker can read.

Opaque vs structured tokens

• Opaque tokens are just random strings with no meaning of their own. The server looks them up in a database to find the associated user and permissions. They are simple, easy to revoke instantly (delete the row), and reveal nothing if leaked beyond access itself.
• Structured tokens such as JWTs carry signed claims inside the token, so the server can validate them without a lookup. They scale well but are harder to revoke before they expire.

For most internal APIs and personal-access-token systems, a random opaque token is the simplest secure choice.

Prefixes like sk_ and pk_

Many APIs prefix their tokens — sk_ for a secret key, pk_ for a publishable key, api_, or a company tag like ghp_. Prefixes are not security by themselves, but they are genuinely useful:

• They make a token instantly recognizable in logs and support tickets.
• They let secret-scanning tools (and services like GitHub) detect and alert on leaked tokens automatically.
• They distinguish dangerous secret keys from safe publishable ones at a glance.

How long should a token be?

Because a token is the only thing standing between an attacker and your API, give it real entropy. 32 random bytes (256 bits) is a strong, common choice; 16 bytes (128 bits) is the minimum. Encode the bytes as Base64URL or hex so the token is safe to place in a header.

Storing and handling tokens

• Hash tokens at rest. Store only a hash (e.g. SHA-256) of each token in your database, just as you would a password, so a database leak does not expose usable tokens.
• Show the full token once. Display it to the user a single time at creation; afterwards show only a prefix and last few characters.
• Support rotation and revocation. Let users create, name, and delete tokens, and expire them on a schedule.
• Scope tokens. Grant the least privilege necessary rather than full-account access.

Generate a token now

The More tab includes an API token generator with selectable prefixes (Bearer, sk_, pk_, api_, or none) and an adjustable byte length, producing URL-safe Base64URL tokens entirely in your browser.