The core confusion

Before comparing them, it helps to clarify what category each thing belongs to:

• API Keys are a credential — a static secret string that identifies a client.
• OAuth 2.0 is a protocol — a framework for delegated authorization, granting access without sharing passwords.
• JWT is a token format — a way of encoding claims in a compact, signed, verifiable structure.

In practice, OAuth 2.0 often uses JWTs as the access token format. So the real comparison isn't three equal alternatives — it's a simple static secret vs. a delegation protocol vs. a token encoding standard the protocol might use. Keeping this distinction in mind makes the rest of the decision much easier.

API keys: simple, static, limited

An API key is a long random string issued to a client that gets sent with every request, usually in a header like Authorization: Bearer <key> or X-API-Key: <key>.

How it works under the hood

1. A developer registers for API access; the server generates a cryptographically random string (often 32+ bytes) and stores a hash of it — never the raw key — associated with the client's account, rate limits, and permissions.
2. The client stores the raw key and attaches it to every request.
3. The server hashes the incoming key and compares it against the stored hash. A simple lookup — no signature verification involved.

GET /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer sk_live_51Hc9F2CZ...

Best practices

• Prefix keys by environment/purpose (sk_live_, sk_test_) — Stripe popularized this so leaked keys are identifiable
• Store only a hash server-side, never the plaintext
• Support rotation without downtime — allow two active keys during a rotation window
• Log usage patterns and alert on anomalies
• Bind keys to IP allowlists where feasible

JWT: a token format, not an auth system

A JSON Web Token is a compact, URL-safe, digitally signed token made of three base64url-encoded parts separated by dots: a header, a payload, and a signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded, that's:

Symmetric vs. asymmetric signing

HS256 (symmetric): the same secret signs and verifies. Simple, but every verifying service can also forge tokens — risky if that secret spreads across many services.

RS256 / ES256 (asymmetric): a private key signs, a public key verifies. Better for distributed systems — your auth server holds the private key, and any number of downstream services verify without ever being able to forge one.

Best practices

• Keep expiry short (5–15 min) and pair with a refresh token flow
• Prefer asymmetric algorithms when multiple services verify independently
• Explicitly whitelist the accepted algorithm server-side — never trust the token's own alg header
• Validate iss and aud claims, not just signature and expiry
• Never store sensitive data in the payload

OAuth 2.0: delegated authorization

OAuth solves a different problem: how does a user grant a third-party app limited access to their resources on another service — without handing over their password? Think "Sign in with Google," or a scheduling app that needs read access to your calendar.

Four roles: the Resource Owner (the user), the Client (the requesting app), the Authorization Server (issues tokens after login and consent), and the Resource Server (holds the data, validates tokens).

Grant types, and when each applies

Token types

Access Token — short-lived, sent with API requests, often (not required) a JWT. Refresh Token — long-lived, stored securely, used only to obtain a new access token without re-prompting login. Rotate refresh tokens on each use to limit the impact of a leak.

Side-by-side

How they fit together in a real system

A common real-world setup combines all three:

1. A user logs in via an OAuth 2.0 authorization code flow, with PKCE if it's a mobile app or SPA
2. The authorization server issues a JWT as the access token — identity, roles, and scopes, signed with RS256
3. Each downstream microservice verifies that JWT locally using the auth server's public key — no network call needed
4. A separate batch job or third-party integration, with no user involved, authenticates via a plain API key or the OAuth client credentials grant

So the real question usually isn't "which one forever" — it's which layer of the system you're authenticating, and what that layer actually needs.

A practical decision guide

Security considerations worth remembering

• Always use HTTPS/TLS. None of these are safe over plain HTTP — tokens and keys are bearer credentials; possession alone grants access.
• Prefer short-lived tokens with refresh mechanisms over long-lived static credentials.
• Never store secrets or sensitive data in a JWT payload — assume it's readable by anyone who intercepts it.
• Rotate and scope API keys — one per client/environment, minimum permissions, rotation without downtime.
• Validate JWT signatures and algorithms explicitly server-side — pin the expected algorithm per key.
• Use PKCE with OAuth 2.0 for any public client that can't securely store a client secret.
• Rotate refresh tokens on use, and treat reuse of an already-rotated token as a signal of theft.
• Audit your redirect URI allowlist — one of the most common real-world OAuth misconfigurations.
• Log and monitor authentication failures and unusual usage patterns across all three methods.

Frequently asked questions