What is API authentication?

API authentication is how a server knows who is calling. It is the API equivalent of "username and password", except the menu of options is wider and the right one depends on who is calling, what they need access to, and how secret the data is. This primer walks through the five common methods, what they look like on the wire, and when each one fits.

No authentication

Some APIs are public. Weather, stock prices, currency rates, mapping services: many of these accept unauthenticated requests, often with a per-IP rate limit. The Go REST API itself accepts a small number of unauthenticated GETs for the docs and demo. Public is the right answer when the data is genuinely public and you do not need per-caller behaviour.

API keys

The simplest authenticated method: a long random string the server hands out, and the client sends on every request. Usually goes in a custom header:

X-API-Key: pk_live_4f8c9b...

Sometimes in the URL (?api_key=...), though that is a bad idea, since URLs leak in logs, history, and Referer headers.

API keys are good for server-to-server calls where the key lives in environment variables. They are bad for browser code (anyone can read them), and they are coarse-grained (one key, one set of permissions). Most APIs that started with API keys eventually add tiered keys (read-only, write, admin) to make them safer.

Basic authentication

The OG of HTTP auth, defined in 1996. The client base64-encodesusername:password and sends it in theAuthorization header:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Decoded, that isuser:password. Note: base64 is not encryption; anyone who sees the header can decode it. Basic auth is only safe over HTTPS.

Use it for: small internal services where simplicity beats sophistication. Avoid for: anything user-facing, since typing your username and password into someone else's app is exactly the password antipattern modern auth tries to avoid.

Bearer tokens

The dominant pattern for modern APIs. The server gives the client an opaque string (the token), and the client sends it in theAuthorization header:

Authorization: Bearer 4f8c9b...e2a1

"Bearer" means: whoever bears (presents) the token is treated as the owner. There is no signature check on the client side; the server validates the token by looking it up.

Bearer tokens combine the simplicity of API keys with two important upgrades: they are tied to a specific user account (so you can show audit logs, revoke per user, apply per-user rate limits), and they are easy to rotate (server deletes the row, and the next request 401s).

Go REST uses bearer tokens. See the dedicatedbearer tokens guide for the full picture.

OAuth 2.0

OAuth is not really an authentication method; it is a delegation framework. It solves a specific problem: how does App A let App B do things on a user's behalf, without giving App B the user's password? The answer involves redirecting the user to App A, having them log in there, and getting App B a scoped token in return.

If you have ever clicked "Continue with Google" or "Authorize this app to access your GitHub", that is OAuth. The output is usually a bearer token that App B then uses for subsequent API calls.

Use OAuth when: third-party apps need to act on behalf of users. Avoid OAuth when: you control both ends, since the OAuth dance adds three round-trips of complexity for no benefit.

JWT

JSON Web Tokens are a token format, not an auth method. A JWT is three base64-encoded segments separated by dots:header.payload.signature. The payload contains claims (user id, expiry, scopes); the signature proves the claims were issued by a trusted server.

The advantage: servers can validate a JWT without a database lookup. Just verify the signature. The downside: revocation is hard. If a JWT is valid for 24 hours, it stays valid for 24 hours even after the user signs out, unless you build a separate revocation list (which defeats the no-database-lookup advantage).

Use JWTs when: you need stateless auth across many services and short token lifetimes are acceptable. Avoid JWTs when: you need instant revocation, since opaque tokens are simpler.

Mutual TLS (mTLS)

The client presents a TLS certificate, and the server verifies it. The connection itself is the authentication. No tokens, no passwords; the cryptographic handshake proves identity.

mTLS is the gold standard for service-to-service auth in zero-trust networks. It is also more operational work than every other method on this list combined: certificate generation, distribution, rotation, expiry handling. Use it when you genuinely need it (regulated environments, financial APIs, machine-to-machine inside a service mesh). Skip it for app-developer-facing APIs.

Choosing

• Public data, no rate-limit personality: no auth.
• Server-to-server, simple: API keys or bearer tokens.
• User-facing, you control both ends: bearer tokens.
• Third-party apps acting on behalf of users: OAuth 2.0.
• Need stateless validation at scale, accept short token lifetimes: JWT.
• Service-to-service, regulated, can afford the operations: mTLS.

Most APIs you build or consume will use bearer tokens, with OAuth on top if third parties are involved. Get those two right, and you are covered for 95% of real-world cases.