JWTs in OAuth 2.0 Flows

OAuth 2.0 and JWTs are separate specifications that work together in modern authentication and authorization systems. OAuth 2.0 defines the authorization framework (flows, token types, roles), while JWT defines the token format. Understanding how they intersect is essential for implementing secure API authentication.

JWTs as OAuth 2.0 access tokens:

The OAuth 2.0 specification does not mandate a specific access token format; tokens can be opaque strings or structured tokens. However, most modern implementations use JWTs as access tokens because they are self-contained: resource servers can validate them without calling the authorization server. RFC 9068 (JSON Web Token Profile for OAuth 2.0 Access Tokens) formalizes this practice, defining required claims like iss, exp, aud, sub, client_id, and jti.

ID tokens in OpenID Connect:

OpenID Connect (OIDC), built on top of OAuth 2.0, mandates that ID tokens must be JWTs. An ID token represents the user's authentication event and contains claims about the user's identity (sub, name, email, email_verified). Unlike access tokens (which are meant for APIs), ID tokens are meant for the client application to learn who the user is.

Authorization Code Flow:
1. User redirects to authorization server
2. User authenticates and consents
3. Server returns authorization code to client
4. Client exchanges code for tokens:
   - access_token (JWT) → for API access
   - id_token (JWT) → for user identity
   - refresh_token → for obtaining new tokens

Client assertions:

JWTs can also authenticate the client itself (not the user) during the token exchange. Instead of sending a client_secret, the client creates a JWT signed with its private key and sends it as a client_assertion. This is more secure than shared secrets for server-to-server communication and is required by some financial APIs (e.g., Open Banking).

Token introspection vs. self-validation:

When access tokens are opaque, resource servers must call the authorization server's introspection endpoint (RFC 7662) to validate them. When access tokens are JWTs, resource servers validate them locally by checking the signature and claims. This eliminates a network round-trip on every API request but trades off the ability to check real-time revocation status. Some architectures use both: local JWT validation for most requests with periodic introspection checks for long-lived sessions.