OAuth 2.0 vs JWT
OAuth 2.0 (RFC 6749) defines authorization flows – how a client gets permission to access resources on behalf of a user or service. JWT (RFC 7519) defines a token structure that can encode any claims and be verified without a database lookup. Many OAuth implementations issue JWTs as access tokens. You can use JWT without OAuth (session tokens, API keys) and OAuth without JWT (opaque tokens).
OAuth 2.0 is an authorization framework – a protocol defining how to delegate access between systems. JWT (JSON Web Token) is a token format – a compact, self-contained way to encode claims. They are not alternatives: OAuth 2.0 commonly uses JWT as its token format. Comparing them is like comparing a shipping protocol to the box format used for shipping.
| Feature | OAuth 2.0 | JWT |
|---|---|---|
| What it is | Authorization framework – defines flows and grant types | Token format – encodes signed claims in Base64URL JSON |
| Scope | Protocol – specifies how delegation happens | Data structure – specifies how a token is encoded |
| Stateful/stateless | Can be either – depends on token type issued | Stateless – all info in the token, no server lookup needed |
| Revocation | Supported – token introspection endpoint (RFC 7662) | Difficult – tokens are valid until expiry without a blocklist |
| Token validation | Opaque tokens require introspection API call | Verify signature locally – no network call needed |
| Payload visibility | Depends on token type | Claims are Base64-encoded – readable without the secret key (only signature needs key) |
| Use cases | Delegated authorization, SSO, social login, API access | Authentication tokens, session tokens, API keys, inter-service auth |
| Standards | RFC 6749, RFC 6750, RFC 7636, PKCE, OIDC | RFC 7519 (JWT), RFC 7515 (JWS), RFC 7516 (JWE) |
| Complexity | High – multiple grant types, flows, endpoints | Low – just a signed JSON payload |
When to use OAuth 2.0
Use OAuth 2.0 when: delegating access across system boundaries (third-party apps accessing user data), implementing SSO, building a public API where clients need scoped access, or integrating with social login providers. OAuth with PKCE is the correct flow for SPAs and mobile apps.
When to use JWT
Use JWT for: stateless session tokens in your own system, inter-service authentication within a trusted network, API keys with embedded claims, and short-lived tokens where revocation is not required. JWTs work well when you want to avoid a database lookup on every request.
Common Mistakes
- Storing sensitive data in JWT payload – JWT claims are Base64-encoded, not encrypted. Anyone with the token can decode and read the payload. Use JWE (encrypted JWT) or put sensitive data in a server-side session instead.
- Using long-lived JWTs without a revocation mechanism – if a JWT is compromised, you cannot invalidate it until it expires. Keep JWT lifetimes short (15 minutes for access tokens) and use refresh tokens for renewal.
- Implementing OAuth 2.0 implicit flow – the implicit flow (response_type=token) was deprecated in OAuth 2.1 because tokens in URL fragments are exposed to the browser history and referrer headers. Use Authorization Code + PKCE instead.
- Confusing authentication with authorization – OAuth 2.0 is an authorization protocol. OpenID Connect (OIDC) adds authentication on top of OAuth 2.0. Use OIDC for login/identity; use OAuth 2.0 alone only for access delegation.
FAQ
Should OAuth 2.0 access tokens be JWTs?
It depends. JWTs as access tokens allow resource servers to validate tokens locally without calling the authorization server – great for performance. Opaque tokens require a network introspection call but can be revoked instantly. For internal microservices with short-lived tokens, JWTs are usually the right choice. For third-party integrations where revocation matters, opaque tokens or short-lived JWTs with a revocation endpoint are better.
What is the difference between OAuth 2.0 and OpenID Connect?
OAuth 2.0 answers 'can this client access this resource?' OpenID Connect (OIDC) adds an ID token (always a JWT) that answers 'who is this user?' OIDC is a thin identity layer on top of OAuth 2.0. Auth0, Google, Microsoft, and Apple all implement OIDC. If you need login and identity, use OIDC. If you only need API access delegation, OAuth 2.0 alone is sufficient.