"Should we use API keys, JWTs or OAuth?" sounds like a choice between three alternatives. It is not. The three answer different questions:
- An API key is a *credential*: a long random secret that identifies a calling application.
- A JWT is a *token format*: a signed JSON document that carries claims.
- OAuth 2.0 is an *authorization framework*: a set of flows for a user to grant an application limited access, which produces access tokens.
An OAuth access token can be a JWT. A JWT can be sent the same way as an API key. Most production APIs use two of the three. Understanding what each one is makes the choice obvious.
API keys
An API key is an opaque random string — 32 bytes from a secure random generator, usually with a prefix like sk_live_ — that the server looks up on every request.
GET /v1/invoices HTTP/1.1
Authorization: Bearer sk_live_51Hq…Strengths: simple to issue, simple to use from scripts and servers, and instantly revocable because the server checks its own database on each call.
Weaknesses: long-lived by default, identify an *application or account* rather than a user, and carry no information on their own — the server needs a lookup for every request.
Use them for: server-to-server access, developer access to your public API, CLI tools and CI jobs. This is what Stripe, OpenAI and SendGrid issue. See how to generate API keys for the design details.
JSON Web Tokens (JWT)
A JWT is three Base64URL segments — header, payload, signature — separated by dots. The payload holds claims such as the subject (sub), audience (aud) and expiry (exp), and the signature lets any holder of the right key verify that the issuer produced it.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTc2MTMxMjAwMH0.7mR…Strengths: self-contained and stateless — a service can verify a JWT with a public key and no database call, which suits microservices and edge functions. Claims travel with the token.
Weaknesses: a JWT cannot be revoked before it expires unless you add a denylist, which gives back the statelessness you wanted. The payload is encoded, not encrypted, so anyone holding the token can read it. Algorithm and key-handling mistakes have a long history of serious vulnerabilities.
Use them for: short-lived access tokens (minutes, not days), identity tokens in OpenID Connect, and passing verified identity between your own services. Paste one into the JWT decoder to see the claims, or use the expiration calculator to reason about lifetimes.
OAuth 2.0
OAuth is the protocol you use when a user wants to let a third-party application act on their behalf — "Allow this app to read your GitHub repositories" — without giving it their password. The user approves a set of scopes, and the application receives:
- an access token, short-lived, sent as a Bearer token on API calls;
- often a refresh token, long-lived, used only to obtain new access tokens.
The access token itself may be opaque (looked up or introspected by the API) or a JWT (verified by signature). OAuth does not dictate the format.
Strengths: delegated, scoped, user-consented access; tokens expire quickly and can be revoked; the user can withdraw consent.
Weaknesses: substantially more moving parts — authorization server, redirect URIs, PKCE, token storage and refresh logic.
Use it for: any case where your API acts on behalf of a user who is not the developer: integrations, marketplaces, "Sign in with…" and mobile apps. For machine-to-machine traffic, the OAuth client credentials flow gives you expiring tokens instead of a permanent key.
Side-by-side comparison
| API key | JWT | OAuth 2.0 access token | |
|---|---|---|---|
| What it is | Opaque random secret | Signed token format | Token issued by an OAuth flow |
| Identifies | Application or account | Whatever the claims say | User + client + scopes |
| Typical lifetime | Months to never | Minutes to hours | Minutes to an hour |
| Verification | Database lookup | Signature check, no lookup | Introspection or JWT check |
| Revocation | Immediate | Hard before expiry | Immediate (opaque) or at expiry |
| Readable by holder | No meaning to read | Yes — payload is just Base64 | Depends on format |
| Complexity | Low | Medium | High |
Decision guide
- Developers calling your API from their own servers? API keys, with scopes and a prefix. Add the client credentials flow later if customers ask for expiring credentials.
- Your own frontend calling your own backend? A session cookie (
HttpOnly,Secure,SameSite) is usually simpler and safer than storing a JWT inlocalStorage. - Third-party apps acting for your users? OAuth 2.0 with the authorization code flow and PKCE. There is no secure shortcut.
- Microservices passing identity to each other? Short-lived JWTs signed with an asymmetric key, verified against a JWKS endpoint.
- Webhooks you send to customers? None of the above — sign the payload with HMAC. See verifying webhook signatures.
How they travel over HTTP
All three are usually sent in the Authorization header with the Bearer scheme, which is why they get confused:
Authorization: Bearer <api key | JWT | OAuth access token>Some APIs use a custom header such as X-API-Key for keys instead. Avoid putting any credential in the query string — URLs end up in logs, browser history and Referer headers. The authorization header builder produces each format correctly.
Frequently asked questions
Is a JWT an API key?
No. A JWT is a token format that carries signed claims and usually expires quickly; an API key is an opaque random secret that is looked up on each request. You can issue long-lived JWTs and use them like API keys, but you lose easy revocation, so most APIs that do this keep a server-side list of valid token IDs anyway.
Is OAuth more secure than API keys?
For delegated user access, yes: tokens are scoped, short-lived and revocable by the user. For simple server-to-server calls, a well-designed API key — high-entropy, scoped, hashed at rest and rotated — is not meaningfully less secure, and far simpler. The OAuth client credentials flow sits between the two.
What is a Bearer token?
"Bearer" is an HTTP authentication scheme meaning "whoever bears this token is authorised". API keys, JWTs and OAuth access tokens can all be sent as Bearer tokens. The term describes how the token is presented, not what it contains.
Should I store JWTs in localStorage?
Avoid it for anything sensitive. Any cross-site scripting bug can read localStorage and exfiltrate the token. An HttpOnly cookie cannot be read by JavaScript at all, which removes that path entirely.