OAuth 2.0 vs JWT: Two Different Jobs That Usually Work as a Team

by Souy Soeng /November 01, 2026

Diagram comparing OAuth 2.0 as an access flow with JWT as a signed token made of header, payload and signature

OAuth 2.0 vs JWT is a common comparison, but the two don't solve the same problem. OAuth 2.0 is an authorization framework that lets an app access your data on your behalf. JWT is a compact, signed token format for carrying claims. One is a process and the other is a format, so they often appear in the same request.

This guide explains each one on its own, then compares them on speed, scaling, ease of setup and cost. It follows a real fitness-app example through the decision and ends with a simple rule of thumb you can use in any design review.

In short

OAuth 2.0 is a framework for delegating access. JWT is a format for signed claims.
JWTs can be verified locally, which makes them fast and easy to scale across servers.
A JWT stays valid until it expires, so revoking one is harder than revoking a looked-up token.
Use OAuth when another app needs your users' data. Use JWT alone between services you control.
Most production systems use both: OAuth runs the flow and issues JWTs as access tokens.

What is the difference between OAuth 2.0 and JWT?

OAuth 2.0 and JWT appear in the same tutorials and often in the same line of code, so people treat them as rivals. They aren't. OAuth 2.0 is a set of rules for who may access what. JWT is a way to package information so that someone else can trust it.

On one side, OAuth 2.0 is an authorization framework. It lets an app act on your behalf, and it defines how tokens get issued. On the other side, JWT is a compact, signed token format. It carries claims between two parties, and a server can verify it without a database lookup.

The mix-up happens because both show up wherever access tokens show up. So "OAuth or JWT?" sounds like a fair question, but it compares a process with a file format. The useful question is different: do you need to let another app act for a user, or do you only need to pass claims you can trust?

OAuth 2.0: an authorization framework that defines how tokens are issued
JWT: a signed token format that carries claims
The real question: delegation, or just verifiable claims?

How OAuth 2.0 works: access on your behalf

You've probably seen a screen that says "Allow this app to see your calendar." That permission screen is OAuth at work, and it's the reason you never hand your password to the app. The key word is authorization. OAuth decides what an app may do. It doesn't decide who you are.

There are four roles. You own the data. The client app wants to use it. The auth server asks for your consent and then issues a token. The resource API holds your data and accepts that token. The app acts for you, but only within the scopes you approved, such as read-only calendar access, and you can take that permission back later.

The most common way a web app gets a token is the authorization code flow. The client sends an authorization request to the auth server, which shows the user a login and consent screen. After the user consents, a code comes back. The client exchanges that code, plus its client secret, for an access token. It then sends that token with each API request, usually in the Authorization header.

Notice that OAuth describes the steps and the roles, not what a token looks like inside. It's a framework, not a format. OAuth is about the handshake, and its job is done once a trusted token is in the client's hands.

Authorization request goes to the auth server
User consents and a code comes back
Client sends the code plus its client secret
Auth server returns an access token

What is a JWT, and what's inside one?

If OAuth is a process, JWT is a thing: a small piece of text you can pass around. JWT stands for JSON Web Token. The claims are written as JSON, the format is built to travel in URLs and HTTP headers, and it acts as a credential you carry. Claims are simply statements, such as "this is user 42" or "this token expires soon."

Every JWT has three parts. The header says which algorithm signed the token, for example HS256. The payload holds the claims, such as a subject of 42 and a role of user. Each part is Base64url-encoded, which is why tokens start with "eyJ". The signature is computed, in this example with HMAC-SHA256 and a secret key. The three parts are then joined with dots into one string.

Only two parties are needed: whoever signs the token and whoever trusts that signature. To check a token, the server recomputes the signature with its key. If it matches, the claims haven't been changed, and there's no session table to query. Because there's no consent screen and no third app, JWT is useful well beyond OAuth.

One important limit: signed doesn't mean secret. Base64url is an encoding, not encryption, so anyone holding the token can read the payload. Trust the signature, but never put a password or other secret in a JWT.

Header: the signing algorithm
Payload: the claims
Signature: proof the claims weren't changed

Speed: which checks a token faster?

An API has to validate a token on every single request, so the cost adds up. To keep the comparison fair, think of OAuth with a plain, opaque reference token on one side and a self-contained JWT on the other.

With an opaque token, the API has to ask the auth server whether the token is valid, which means an extra network call per check. You can cache those lookups to speed things up. With a JWT, the API verifies the signature locally. There's no extra call, and the only thing to cache is the signing key.

JWT wins this round, because verifying a signature is quick CPU work on the API itself, with no round trip. But it isn't either-or. An OAuth server can issue JWTs as its access tokens and get the same speed. This round is really about token format, not about OAuth.

Opaque token: ask the auth server, extra call per check
JWT: verify the signature locally, no extra call
OAuth servers can issue JWTs to get the same benefit

Scaling with JWTs, and why revocation is harder

When traffic grows, you add more API servers. Each one needs a source of trust. With JWTs, a mobile app sends its token to a load balancer, which spreads requests across several API servers. Each server checks the signature on its own, with no shared session store. That's what stateless scaling means.

The catch is revocation. If a user logs out or a token leaks, every server keeps accepting it until it expires. You can add a blocklist, but that brings the lookup back and gives up part of the benefit. The common fix is short-lived access tokens combined with refresh tokens.

So JWT wins on stateless scale, and lookups win on instant revocation. Choose based on which matters more for your system.

Which is easier to set up?

Picture day one: an empty project and a deadline. With OAuth 2.0, you need an auth server, a registered client ID, a redirect URI, defined scopes and a consent screen for users. Hosted providers help, but every piece still needs configuring.

JWT alone is closer to a library call. In the example below, jwt.sign creates a token from a claim and a key, and jwt.verify checks it, throwing an error if anyone tampered with the token. When your own app talks to your own API, there's far less to build, so JWT alone wins this round. OAuth's extra parts only pay off when someone else's app is involved.

OAuth setup: auth server, client ID, redirect URI, scopes, consent screen
JWT alone: sign a token, verify a token

# JWT alone: sign once, verify anywhere
const t = jwt.sign({ sub: 42 }, key)
jwt.verify(t, key)
# throws if the token was tampered with

Is OAuth worth the cost? Real use cases

OAuth takes time and money to set up and run, and the situation where that cost pays off is third-party access. Imagine you want a service called PrintShop to print your photos. One option is to share your password, which gives full account access and is a real risk. The better option is OAuth consent: you approve, and PrintShop receives a short-lived token limited to a scope like photos.read, which you can revoke.

In practice, you rarely choose between the two. A mobile app built in React Native runs the OAuth flow with an auth server such as Auth0 or Keycloak, which issues a signed JWT. The app sends that JWT to a Node.js resource API, which verifies it using public keys published at a JWKS endpoint. OAuth handles consent, scopes and who gets a token. JWT is the token the API verifies on its own.

Now picture a fitness app that adds workouts to each user's Google Calendar. The data lives in Google Calendar, not your database, so you need the user's consent. That points to the OAuth code flow. You receive an access token in whatever format Google chooses, call the API, and the event is created.

Inside your own backend, the picture changes. When your workout API calls your stats service, there's no third party, so a JWT signed by your backend can carry the user's ID and role. OAuth handles access to Google's data, and JWT handles trust between your own services.

OAuth 2.0 or JWT: which should you pick?

The decision comes down to one question: is another app getting access? Pick OAuth if other apps, or other companies, need access to your users' data, or if you want "Sign in with" style flows. Don't try to rebuild that yourself with raw JWTs.

Pick JWT if you only need to pass verifiable claims between services you control. And if you need both, which is the setup most production systems use, let OAuth issue JWTs as its access tokens. In most real systems, "OAuth versus JWT" turns out to be "OAuth with JWT."

Delegating access to another app: OAuth 2.0
Passing trusted claims between your own services: JWT
Both: use OAuth to issue JWTs

Key takeaways

OAuth 2.0 delegates access on a user's behalf; JWT is a signed, compact format for claims.
JWTs verify quickly and scale statelessly because no lookup is needed.
Revoking JWTs is hard, so use short expiry times plus refresh tokens.
OAuth costs more to set up, but it secures third-party access.
Together, OAuth provides the flow and JWT provides the token.

Frequently asked questions

Is JWT a replacement for OAuth 2.0?

No. OAuth 2.0 is a framework that defines how access is granted and tokens are issued, while JWT is a format for the token itself. They work at different layers, so one can't replace the other.

Can OAuth 2.0 use JWTs as access tokens?

Yes. OAuth doesn't dictate what a token looks like, so an auth server can issue JWTs as access tokens. APIs can then verify them locally, often using public keys from a JWKS endpoint.

Is the data inside a JWT encrypted?

Not by default. The parts are Base64url-encoded, which anyone can decode, and the signature only proves the contents weren't changed. Never store passwords or other secrets in the payload.

How do you revoke a JWT before it expires?

A valid JWT keeps working until it expires, which makes instant revocation difficult. You can add a blocklist, but that brings back a lookup. The common approach is short-lived access tokens paired with refresh tokens.

Do I need OAuth if only my own app calls my own API?

Usually not. When every app involved is yours, signing and verifying JWTs is much simpler to set up. OAuth's extra parts pay off when a third-party app needs access to your users' data.

Does OAuth 2.0 tell an app who the user is?

OAuth 2.0 is about authorization: it decides what an app may do, not who you are. It grants an app limited access within the scopes the user approved.

Watch the full video on YouTube →

Tag

Ad