OAuth 2.0 vs JWT: A Framework and a Format

OAuth says how a token is obtained; JWT is one way to write a token down; the question "which one" mixes them.

OAuth 2.0 and JWT answer different questions, so they are not alternatives. OAuth is a framework for obtaining tokens: who asks, who approves and how the token is delivered. JWT is a format for writing a token: signed JSON claims. An OAuth access token may be a JWT or an opaque string, and an OpenID Connect ID token is always a JWT. "Should we use OAuth or JWT?" usually means "how should we issue tokens, and what should they look like?"

Obtaining a token and writing it down, as separate layers

An API call with a token
- How the token was obtained: OAuth 2.0 flows
  - Authorization code with PKCE, a user signs in
  - Client credentials, a service acts for itself
  - Refresh token, a new access token for an old one
- How the token is written: formats
  - Opaque string, the API asks the issuer what it means
  - JWT, signed claims the API verifies itself

OAuth without JWT. Many providers issue opaque access tokens. The API validates each by asking the authorization server through introspection, RFC 7662, which also makes revocation immediate.

JWT without OAuth. An application can sign its own JWTs after a password login and accept them on its API. That uses the format and none of the framework: no delegation, no consent, no standard flows.

Both together. The common case is an OAuth authorization server issuing JWT access tokens, defined in RFC 9068, which APIs validate locally, and OIDC ID tokens, which are JWTs by definition.

The real decisions. Whether third parties or several applications need delegated access, which points to OAuth; and whether APIs should verify tokens locally or ask the issuer, which decides between JWT and opaque.

← → move through sections and cards