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

DimensionOAuth 2.0JWT
What it isAuthorization framework with defined flowsCompact signed (or encrypted) token format
Answers”May this client access this resource on the user’s behalf?""What claims did this issuer sign?”
StateAuthorization server issues and can revoke tokensSelf-contained; verified by signature, exp, aud, iss
RevocationSupported at the server (revocation endpoint, short TTL plus refresh rotation)None until expiry unless you add state
Sign-inNeeds OpenID Connect on top for identityCarries claims only
Access token formatOpaque 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, and iss; 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.