API Authentication: JWT vs API Keys vs OAuth Explained

API authentication is the process of verifying that a client is allowed to call your API — and the three most common approaches (JWT, API keys, and OAuth 2.0) each make different trade-offs around simplicity, security, and who's doing the authenticating. If you're building or integrating an API right now, choosing the wrong method means retrofitting auth logic across every client and service that depends on it.

This post breaks down exactly what each method does, when to use it, and where it breaks down. You can decode any JWT you're working with using the JWT Decoder to inspect claims in real time.

What is the difference between JWT, API keys, and OAuth?

JWT (JSON Web Token) is a self-contained, signed token that encodes identity and claims directly into a URL-safe string. API keys are opaque random strings that identify a caller but contain no embedded data. OAuth 2.0 is a delegation protocol — it lets a user grant a third-party app limited access to their account without sharing their password.

These three aren't really competing for the same job:

• API keys identify who is calling (your app, a machine)
• JWTs identify who the user is and carry claims about them
• OAuth 2.0 handles who gave permission to act on behalf of someone else

Most production systems use a combination. Stripe uses API keys for machine-to-machine access. GitHub uses OAuth for third-party apps and JWTs internally for short-lived session tokens.

When should you use API keys?

API keys work best for server-to-server communication where there's no human user in the loop. A key like sk_live_abc123xyz goes in an Authorization header on every request. The server looks it up in a database, finds the associated account, and decides what that caller is allowed to do.

The appeal is simplicity. You generate a key, hand it to a developer, and they're making authenticated requests in minutes. Rate limiting, usage tracking, and revocation are all straightforward — tied to the key ID in your database.

The downside: API keys are opaque and stateful. Every request requires a database lookup. There's no standard format (every provider invents their own), and keys are long-lived by default, which means a leaked key keeps working until you manually revoke it. GitHub's secret scanning exists precisely because developers keep committing API keys to public repos by accident.

Use API keys when:

• Callers are services, not end users
• You want simple revocation and per-key rate limiting
• You don't need to embed claims or user context in the token
• The integration needs to stay simple for third-party developers

When should you use JWTs?

JWTs make sense when you need to pass verified claims between services without a database roundtrip on every request. A JWT encodes a JSON payload — typically including a sub (subject/user ID), iat (issued at), exp (expiration), and custom claims — and signs the whole thing with a secret or private key.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxMTY0NDgwMH0
.Hs7RmCqQqLDdXkLpNh5NuSB7AxAUcGNrQKxezfTq6wM

The middle section (payload) decodes to:

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1711644800
}

Any service that knows the signing secret (or has the public key, for RS256) can verify the signature and trust the claims — no database call needed. This is why microservices love JWTs: a user authenticates once, gets a JWT from an auth service, and can use that token across a dozen downstream services without any of them needing to call back to the auth server.

Paste any JWT into the JWT Decoder and you'll see the header, payload, and signature parsed out instantly. Useful when debugging auth issues or auditing what a third-party token actually contains.

JWTs have real trade-offs though. Once issued, you can't revoke a JWT before it expires — unless you maintain a blocklist (which brings the database back). Short expiration windows (15–60 minutes) with refresh tokens are the standard workaround. Also: JWTs are signed, not encrypted. Anyone with the token can read the payload; don't put sensitive data (SSNs, passwords, private keys) in JWT claims.

Use JWTs when:

• You're authenticating end users and want stateless sessions
• Multiple services need to verify identity without central coordination
• Short-lived tokens with refresh rotation are acceptable
• You need to embed roles, permissions, or user metadata in the token itself

When should you use OAuth 2.0?

OAuth 2.0 is not a replacement for JWTs or API keys — it's a protocol that coordinates authentication flows and often produces JWTs or API keys as its output. The core use case: a user wants to let your app access their data on another service without giving you their password.

The classic flow (Authorization Code):

1. Your app redirects the user to GitHub (or Google, Stripe, etc.)
2. The user logs in and approves specific permissions ("read repos", "access email")
3. GitHub redirects back to your app with an authorization code
4. Your app exchanges the code for an access token (often a JWT or opaque token)
5. Your app uses the access token to call GitHub's API on the user's behalf

OAuth 2.0 has four grant types for different scenarios:

Grant type	Use case
Authorization Code	User-facing web apps (most common)
Authorization Code + PKCE	Mobile and SPA apps (no client secret)
Client Credentials	Machine-to-machine, no user involved
Device Code	Smart TVs, CLIs with limited input

The Client Credentials grant is effectively OAuth's answer to API keys — two services authenticating with each other using a client_id and client_secret to get a short-lived access token.

Use OAuth 2.0 when:

• Users need to grant your app access to their accounts on other services
• You're building a platform where third-party apps connect to your service
• Delegated, scope-limited access is a requirement
• You want centralized session management and revocation through an auth server

What does the JWT signature actually protect?

The JWT signature protects the integrity of the token, not its confidentiality. HMAC-SHA256 (HS256) creates the signature using a shared secret: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret). If anyone modifies the payload — changing "role": "user" to "role": "admin" — the signature won't match and verification fails.

RS256 and ES256 use asymmetric keys instead. The auth server signs with a private key; any service can verify with the public key, which can be safely distributed. This is how Google and Auth0 publish JWKS (JSON Web Key Sets) endpoints — services fetch the public keys and verify tokens locally.

One critical mistake: never use alg: none. Early JWT libraries had a vulnerability where an attacker could strip the signature and set the algorithm to none, tricking naive verifiers. Always explicitly validate the alg claim against what you expect.

Quick reference

Method	Stateful?	Revokable instantly?	Carries claims?	Best for
API key	Yes (DB lookup)	Yes	No	Machine-to-machine
JWT (HS256)	No	No (until exp)	Yes	User sessions, microservices
JWT (RS256)	No	No (until exp)	Yes	Distributed systems, third-party verification
OAuth 2.0 access token	Depends	Yes (via auth server)	Sometimes	Delegated user access
OAuth 2.0 + PKCE	Depends	Yes	Sometimes	Mobile/SPA apps

Algorithm comparison:

Algorithm	Key type	Verification
HS256	Shared secret	Any party with the secret
RS256	RSA key pair	Anyone with the public key
ES256	ECDSA key pair	Anyone with the public key (smaller keys than RS256)

The right choice usually isn't API keys or JWTs or OAuth — it's knowing which layer handles which problem. API keys for programmatic access. JWTs for user identity. OAuth when a third party needs delegation. Decode a JWT you're currently working with in the JWT Decoder to inspect exactly what claims are in play.