Overview
Treat OAuth and JWT as different layers: OAuth defines how a client obtains limited access to a resource, and JWT (RFC 7519) defines a signed token format that OAuth access tokens and OpenID Connect ID tokens often use. Use OAuth for delegation and “sign in with” flows; use JWTs for short-lived signed claims; do not use a long-lived JWT as a browser session (jwt-vs-session-cookies). As of 2026-10-01 OAuth 2.1 is still an IETF draft (draft-16, September 2026); the current normative guidance is RFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025).
Comparison
| Dimension | OAuth 2.0 | JWT |
|---|---|---|
| What it is | Authorization framework with defined flows | Compact signed (or encrypted) token format |
| Answers | ”May this client access this resource on the user’s behalf?" | "What claims did this issuer sign?” |
| State | Authorization server issues and can revoke tokens | Self-contained; verified by signature, exp, aud, iss |
| Revocation | Supported at the server (revocation endpoint, short TTL plus refresh rotation) | None until expiry unless you add state |
| Sign-in | Needs OpenID Connect on top for identity | Carries claims only |
| Access token format | Opaque or JWT (RFC 9068 profile) | n/a |
Pick OAuth when
Pick OAuth when access is delegated or issued by an authorization server.
- User-delegated access and “sign in with Google, GitHub, or Apple”: Authorization Code flow with PKCE, plus OpenID Connect for identity.
- Machine-to-machine access: Client Credentials grant with narrow scopes.
- Follow RFC 9700: PKCE for all clients, exact redirect URI matching, no implicit grant, no password grant, and refresh-token rotation or sender-constrained tokens (DPoP or mutual TLS) for public clients.
- Use a hosted provider or a maintained library (Auth0, Clerk, Supabase Auth, Keycloak); do not build an authorization server yourself.
Pick JWT when
Pick JWT for short-lived signed claims that a verifier can check without a lookup.
- Service-to-service calls and gateway-to-service claims (user ID, role, tenant ID), with lifetimes in minutes.
- Access tokens issued by an authorization server that resource servers validate locally.
- Validate every token: signature with a pinned algorithm,
exp,aud, andiss; rotate signing keys and publish them via a JWKS endpoint. - Never put secrets in the payload; a signed JWT is readable by anyone who holds it.
Sessions
User sessions in a browser belong in an opaque, server-side session cookie. See jwt-vs-session-cookies and auth-sessions. If you use OAuth for login, create your own session after the callback instead of storing the provider’s tokens in the browser.
FAQ
Is OAuth the same as JWT?
No; OAuth is a delegation protocol and JWT (RFC 7519) is a signed token format, so they are different layers. OAuth access tokens and OpenID Connect ID tokens often use the JWT format.
Can I use OAuth for user login?
Yes, with OpenID Connect on top for identity, using the Authorization Code flow with PKCE. After the callback, create your own server-side session instead of storing the provider’s tokens in the browser.
Is OAuth 2.1 final?
Not as of 2026-10-01; OAuth 2.1 is still an IETF draft (draft-16, September 2026). Follow RFC 9700, the OAuth 2.0 Security Best Current Practice, for current guidance.
Which OAuth grants should I avoid?
Do not use the implicit grant or the password grant, per RFC 9700. Use PKCE for all clients and exact redirect URI matching.