JWT vs OAuth2: What's the Difference?

They answer different questions This confusion is extremely common: **JWT is a token format**. **OAuth2 is an authorization framework** — a set of flows for getting a client delegated access to a resource on a user's behalf. You can use OAuth2 without ever seeing a JWT, and you can use JWTs without any OAuth2 flow at all.

What JWT actually is A JWT (JSON Web Token) is a compact, URL-safe string with three base64url-encoded parts separated by dots: a header, a payload, and a signature. It's a **container format** for claims, nothing more. It says nothing about how the token was issued, who can request one, or what scopes mean.

What OAuth2 actually is OAuth2 is a protocol that defines **how a client obtains an access token** from an authorization server, typically after a resource owner (the user) grants consent. It defines flows like:

• Authorization Code — the standard flow for web and mobile apps
• Client Credentials — machine-to-machine, no user involved
• Refresh Token — exchanging a long-lived credential for a new access token

Where OpenID Connect (OIDC) fits in OIDC is a thin identity layer built on top of OAuth2. It standardizes an `id_token`, which **is always a JWT**, containing claims about who the user is (`sub`, `email`, `name`). This is the layer most "Login with Google" buttons actually use.

A concrete example 1. Your app redirects the user to an OAuth2 authorization server. 2. The user logs in and consents to scopes like `read:profile`. 3. The authorization server redirects back with an authorization code. 4. Your backend exchanges the code for an access token and, if using OIDC, an `id_token`. 5. If the access token is a JWT, your resource server can verify its signature locally instead of calling back to the authorization server on every request.

Common mistakes - Assuming "OAuth2" means "JWT" — it doesn't, always check what your provider actually issues. - Treating an OAuth2 access token as proof of identity — access tokens are about authorization (what you can do), not authentication (who you are). Use the `id_token` for identity. - Skipping audience (`aud`) validation on access tokens meant for a specific API.

Checklist - Know whether your access tokens are JWTs or opaque strings — check the provider's docs, don't assume. - Use `id_token` (JWT, OIDC) for authentication, access tokens for authorization. - Validate `aud`, `iss`, and `exp` on any JWT you accept, regardless of who issued it. - Never conflate "I have a valid token" with "I know who this user is" unless you're looking at an `id_token`. - If you're building an API, prefer short-lived JWT access tokens plus a proper OAuth2 refresh flow rather than rolling your own scheme.