API Authentication Explained: API Keys, OAuth and Bearer Tokens

API keys: the simplest option

An API key is a long random string that identifies the caller. You include it in a request — usually in a header like X-API-Key, sometimes as a query parameter — and the server looks it up, checks it is valid, and applies the permissions and rate limits attached to it. Keys are easy to issue, easy to revoke, and easy to scope: one key per application, per environment, per integration.

The weakness of an API key is that it identifies a key, not a person. Whoever holds the key has all of its powers, so a leaked key is a live credential until someone revokes it. Never put API keys in client-side code, public repositories or URLs that get logged — query parameters end up in server logs, so headers are the safer place. Rotate keys periodically, and give each key the smallest set of permissions it needs.

Basic Auth: username and password in a header

Basic Auth is the oldest HTTP authentication scheme, and the simplest to understand: the client sends Authorization: Basic followed by the Base64 encoding of username:password. The server decodes it, checks the credentials, and answers. It is built into every HTTP client and trivially easy to test, which is why internal tools and simple APIs still use it.

Two things make Basic Auth weak on its own. First, Base64 is encoding, not encryption — anyone who intercepts the header can decode it instantly, so Basic Auth is only safe over HTTPS, always. Second, it sends the real credentials with every request, so a single leaked request leaks the password. A Basic Auth generator can build the header for you while testing, but for a public-facing API, prefer tokens: they can expire, be scoped, and be revoked without changing the user's password.

Authorization: Basic YWRtaW46c3VwZXJzZWNyZXQ=
Base64-decoded: admin:supersecret

// Use HTTPS — Base64 is not encryption.

Bearer tokens and JWTs

A Bearer token is a credential the client presents in an Authorization: Bearer <token> header, and the name says it all: whoever bears the token is treated as its owner. In practice the token is usually a JWT — a JSON Web Token with three Base64 parts: a header naming the signing algorithm, a payload carrying claims like the user ID and expiry time, and a signature the server can verify without a database lookup.

Bearer tokens are the standard for modern APIs because they are stateless and short-lived: an access token might last an hour, and a separate refresh token is used to obtain a new one. Keep expiry times short so a stolen token is useful only briefly, and store tokens where JavaScript cannot easily reach them — HttpOnly cookies are safer than localStorage, which any cross-site scripting vulnerability can read. And never put secrets in a JWT payload: the first two parts are just Base64, readable by anyone who holds the token.

OAuth 2.0: letting users sign in with another service

OAuth 2.0 solves a different problem: letting a user grant your app limited access to their account on another service, without giving you their password. The familiar "Sign in with Google" button is OAuth. The flow is: your app redirects the user to the provider, the user approves the requested permissions (called scopes), the provider sends your app an authorization code, and your app exchanges that code for an access token — all without ever seeing the user's password.

Scopes are the heart of OAuth security: an app that only asked to read your calendar cannot also read your email, because its token carries only the scopes it was granted. Public clients — mobile apps and single-page apps — add a PKCE challenge so an intercepted code cannot be exchanged by someone else. If you are building an app that acts on behalf of users, OAuth is the answer; if you are building a server-to-server integration, a simple API key or a client-credentials token is usually enough.

• Authorization code flow — the standard flow for web apps.
• Scopes — the permissions a token carries; ask for the minimum.
• Access token — short-lived, used for API calls.
• Refresh token — long-lived, used only to get new access tokens.
• PKCE — protects the code exchange in public clients.

Security rules that apply to all of them

Whatever method you use, the same rules apply. Always use HTTPS — credentials sent over plain HTTP can be intercepted, and a stolen credential is a stolen identity until it expires or is revoked. Give every credential the least privilege it needs: read-only keys for dashboards, separate keys per environment, and scopes that cover only what the app actually does.

Treat secrets like secrets. Never commit them to version control, never paste them into chat logs or screenshots, and load them from environment variables or a secret manager instead of hardcoding them. Set expiry and rotation: short-lived tokens, keys that rotate on a schedule, and a revocation path you have actually tested. Finally, monitor usage: unexpected spikes, calls from unfamiliar locations, or a sudden flood of 401 errors are the first signs that a credential has leaked — and the faster you notice, the smaller the damage.