How do JWTs work in microservices?
JWTs (JSON Web Tokens) are the backbone of stateless, decentralized authentication in microservice architectures. They eliminate the need for centralized session storage by allowing each service to locally verify the token's validity and extract user identity, ensuring high scalability and performance.
In a microservice architecture, the API Gateway acts as the central security enforcement point. It is responsible for intercepting all incoming requests, extracting the JWT from the Authorization: Bearer header, and validating its signature, expiration, and other key claims before routing the request to the appropriate downstream service[reference:0][reference:1]. The gateway can also be configured to refresh public keys from a JWKS (JSON Web Key Set) endpoint to handle key rotation without downtime[reference:2]. Once validated, the gateway can forward the request (often with the original JWT or a modified one containing user context) to downstream services, which can trust the token because it was already verified at the edge. This pattern reduces the security burden on individual microservices, as they can rely on the gateway to perform the cryptographic verification[reference:3]. For extremely high-performance requirements, the gateway may optionally use a Redis-based token validation to enable immediate revocation, while still maintaining low latency[reference:4].
- 1
Local Validation (JWKS): Each service independently verifies the JWT's signature using a public key from the authorization server, cached locally. This method is extremely fast (no network calls) and highly scalable, but lacks real-time revocation; a compromised token remains valid until its expiration[reference:5][reference:6].
- 2
Remote Introspection (RFC 7662): The service calls the authorization server's introspection endpoint to validate the token on every request. This allows real-time revocation and supports opaque tokens, but increases latency and creates a potential single point of failure (SPOF)[reference:7][reference:8].
- 3
Hybrid Approach: Many production systems use a mix: JWKS for most high-traffic read operations, and fallback to introspection for critical, write-heavy operations where immediate revocation is essential[reference:9].
When a service needs to act on behalf of an end user while calling another service (e.g., email-service creating a comment via comment-service), the Token Propagation pattern is used. The caller includes the original user's JWT, and the receiving service extracts the user ID from the sub claim[reference:12]. In scenarios where a machine-to-machine (M2M) call must also carry user context, the calling service can obtain a JWT for itself (e.g., via Client Credentials grant) and include an additional X-User-Id header containing the user identifier[reference:13]. To prevent forgery, the receiving service should treat this header as untrusted and only accept it if the M2M token is from a trusted service (validated via its sub claim) and the API is accessed over a secure, internal network (e.g., a service mesh with mTLS).