How do JWTs work in microservices?

Question

Accepted Answer

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]. **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]. **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]. **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]. ```javascript
// M2M flow: Service A requests a JWT for itself using its client credentials.
const axios = require('axios');
const qs = require('qs');

// Service A obtains its own JWT for M2M communication.
const getServiceToken = async () => {
    const response = await axios.post('https://auth-server.com/oauth/token', 
        qs.stringify({
            grant_type: 'client_credentials',
            client_id: 'service-a-client-id',
            client_secret: 'service-a-client-secret',
            scope: 'read:comments'
        }),
        { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
    );
    return response.data.access_token;
};

// Service A calls Service B's API, passing its JWT in the Authorization header.
const callServiceB = async () => {
    const serviceToken = await getServiceToken();
    const response = await axios.get('https://service-b.com/api/comments', {
        headers: { 'Authorization': `Bearer ${serviceToken}` }
    });
    return response.data;
};
```
This pattern, known as the OAuth 2.0 Client Credentials Grant, is ideal for backend-to-backend communication where no user context is involved[reference:10]. Each service is registered with its own `client_id` and `client_secret`, and the token's `aud` (audience) and `scope` claims must be validated to ensure the caller is authorized to access the specific endpoint. 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). ```javascript
// A service acting on behalf of the user propagates the JWT received from the gateway.
const callServiceOnBehalfOfUser = async (userJwt, commentData) => {
    const response = await axios.post('https://comment-service.com/comments', commentData, {
        headers: { 'Authorization': `Bearer ${userJwt}` }
    });
    return response.data;
};

// Service B extracts the user ID from the 'sub' claim and uses it.
// In NestJS, using @nestjs/jwt and Passport.
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
    constructor() {
        super({
            jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
            secretOrKey: publicKey, // The public key from the IdP (e.g., via JWKS)
            algorithms: ['RS256']
        });
    }
    async validate(payload: any)

How do JWTs work in microservices?

How do JWTs work in microservices?

Scenario Questions

Follow-up Questions