OAuth vs JWT: Protocol or Token Format?
OAuth 2.0 is an authorization framework for delegated access; JWT is a token format. They solve different problems and are often used together.
OAuth 2.0 defines flows by which an app obtains delegated access to resources without handling user passwords, issuing access and refresh tokens. JWT is a compact, signed token format that can carry claims and be verified without a database lookup. OAuth often issues JWTs as access tokens, but you can use JWTs without OAuth and OAuth with opaque tokens. They are complementary, not competitors.
| OAuth 2.0 | JWT | |
|---|---|---|
| What it is | Authorization framework | Token format |
| Scope | Delegated access flows | Encodes claims |
| Verification | Depends on token type | Signature (stateless) |
| Used together | Issues tokens | Can be the token |
| Best for | Third-party access | Stateless claims |
How they relate
Use OAuth when you need delegated authorization - letting users grant an app access to their data on another service (the "Sign in with X" and API-access flows). Use JWT when you need a self-contained, verifiable token carrying identity or claims. An OAuth provider commonly returns a JWT access token, so the right framing is "which OAuth flow" plus "which token format."
In CI
Pipelines often exchange OAuth client credentials for short-lived tokens to call APIs; store secrets in the CI secret store, never in code. On managed runners, mask token outputs and use OIDC where possible to avoid long-lived secrets.
The verdict
Need delegated access and standard login/authorization flows: OAuth 2.0. Need a stateless, verifiable token carrying claims: JWT. The common, correct setup is OAuth flows that issue JWT access tokens - they are layers of the same system, not an either/or.