OAuth 2.0 vs JWT

"Should I use OAuth 2.0 or JWT?" — this question appears constantly in developer forums, and it reveals a fundamental misunderstanding. OAuth 2.0 and JWT are not alternatives or competitors. They operate at completely different layers: OAuth 2.0 is an authorization framework that defines how applications get permission to access resources. JWT is a token format that defines how to encode and transmit claims securely. OAuth 2.0 often uses JWTs, making them complementary — not competing — technologies.

This guide clears up the confusion once and for all. You will understand what each technology does, how they relate to each other, when to use each one, and how modern systems combine them.

The Biggest Misconception: They Are Not Competitors

Comparing OAuth 2.0 and JWT is like comparing "the postal system" with "an envelope." The postal system (OAuth) defines how mail gets from sender to recipient — the rules, routes, and verification. The envelope (JWT) is the container that holds the letter. They work together; they don't replace each other.

What Is JWT?

JWT (JSON Web Token) is a compact, URL-safe token format defined in RFC 7519. It encodes a set of claims (user identity, permissions, expiration) as a JSON object, then signs it cryptographically so the recipient can verify it has not been tampered with.

JWT is self-contained — all the information needed to verify and trust the token is inside it. No database lookup is required. This makes JWT ideal for stateless authentication in distributed systems.

What Is OAuth 2.0?

OAuth 2.0 is an authorization framework (RFC 6749) that enables applications to obtain limited access to user accounts on third-party services. It defines the roles, flows, and protocols for delegated authorization — allowing users to grant apps access to their data without sharing passwords.

OAuth 2.0 Roles

Common OAuth 2.0 Flows

OAuth 2.0 vs JWT: Comparison Table

How OAuth 2.0 Uses JWT

In modern implementations, OAuth 2.0 authorization servers typically issue JWTs as access tokens. This combines OAuth's authorization flow with JWT's stateless verification:

• Access Tokens as JWTs: The resource server can verify the token locally using the authorization server's public key — no introspection endpoint call needed.
• ID Tokens (OpenID Connect): Always JWTs. They contain the authenticated user's identity claims (name, email, picture) and are returned alongside access tokens.
• Refresh Tokens: Usually opaque strings (not JWTs) because they are always validated server-side and benefit from easy revocation.

User clicks "Login with Google"
        ↓
Browser redirects to Google Authorization Server
        ↓
User grants permission
        ↓
Google returns authorization code to your app
        ↓
Your server exchanges code for tokens:
  • Access Token (JWT) — for calling Google APIs
  • ID Token (JWT) — user identity (name, email, picture)
  • Refresh Token (opaque) — for getting new access tokens
        ↓
Your app uses the access token (JWT) to call Google Calendar API
        ↓
Google verifies JWT signature → grants access to calendar data

OAuth 2.0 Authorization Code Flow (with PKCE)

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended flow for web and mobile applications in 2026. Here is the complete sequence:

// Step 1: Generate PKCE challenge
const codeVerifier = generateRandomString(128)
const codeChallenge = base64url(sha256(codeVerifier))

// Step 2: Redirect user to authorization server
const authUrl = new URL("https://accounts.google.com/o/oauth2/v2/auth")
authUrl.searchParams.set("client_id", CLIENT_ID)
authUrl.searchParams.set("redirect_uri", "https://myapp.com/callback")
authUrl.searchParams.set("response_type", "code")
authUrl.searchParams.set("scope", "openid email profile")
authUrl.searchParams.set("code_challenge", codeChallenge)
authUrl.searchParams.set("code_challenge_method", "S256")
// → User sees Google consent screen

// Step 3: User approves → Google redirects back with code
// GET https://myapp.com/callback?code=AUTH_CODE_HERE

// Step 4: Exchange code for tokens (server-side)
const tokenResponse = await fetch("https://oauth2.googleapis.com/token", {
  method: "POST",
  body: new URLSearchParams({
    client_id: CLIENT_ID,
    client_secret: CLIENT_SECRET,
    code: authCode,
    code_verifier: codeVerifier,  // PKCE verification
    redirect_uri: "https://myapp.com/callback",
    grant_type: "authorization_code"
  })
})

const { access_token, id_token, refresh_token } = await tokenResponse.json()
// access_token = JWT (for calling Google APIs)
// id_token = JWT (user identity — decode to get name, email)
// refresh_token = opaque string (for getting new access tokens)

Simple JWT Authentication Flow (No OAuth)

For first-party applications (your frontend talking to your own backend), JWT authentication without OAuth is simpler and perfectly appropriate:

// Simple JWT auth — no OAuth needed for first-party apps

// Login: user sends credentials directly to YOUR server
const response = await fetch("/api/auth/login", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "alice@example.com", password: "secret" })
})
const { accessToken } = await response.json()
// accessToken is a JWT signed by YOUR server

// API requests: send JWT in Authorization header
const data = await fetch("/api/profile", {
  headers: { Authorization: `Bearer ${accessToken}` }
})

// Server-side: verify JWT with YOUR signing key
const payload = jwt.verify(accessToken, YOUR_SECRET)
// → { sub: "user_123", role: "admin", exp: ... }

This is dramatically simpler than OAuth because there is no third-party authorization server, no consent screen, no authorization code exchange, and no client registration. You control both sides of the conversation.

OpenID Connect: OAuth + Authentication + JWT

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that adds authentication. While OAuth 2.0 only handles authorization ("can this app access this resource?"), OIDC adds authentication ("who is this user?").

OIDC introduces the ID Token — a JWT that contains the authenticated user's identity claims (name, email, picture, email_verified). This is what powers "Login with Google," "Sign in with Apple," and other social login buttons.

OpenID Connect = OAuth 2.0 + Authentication + ID Token (JWT)

OAuth 2.0 alone:
  → "App X can access User Y's calendar" (authorization only)

OAuth 2.0 + OpenID Connect:
  → "This user is alice@example.com" (authentication)
  → "App X can access her calendar" (authorization)
  → ID Token (JWT): { sub: "123", name: "Alice", email: "alice@example.com" }
  → Access Token: for calling APIs

In practice: when you add scope: "openid email profile" to an OAuth request, you are using OIDC. The authorization server returns an ID Token (JWT) alongside the access token. Most "Login with X" implementations use OIDC, not raw OAuth 2.0.

When to Use OAuth 2.0

When to Use JWT (Without OAuth)

Common Developer Mistakes

Best Practices

Frequently Asked Questions

Related Articles & Tools