JWT token propagation in Microservices - Architecture Diagram

System Overview - JWT token propagation

This system demonstrates how a JSON Web Token (JWT) is propagated securely across multiple microservices to authenticate and authorize user requests. The key requirement is to ensure that each microservice can verify the token without needing to re-authenticate the user, enabling seamless and secure communication.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+----------------+       +----------------+       +----------------+
|  Service A     | ----> |  Service B     | ----> |  Service C     |
| (Auth Verify)  |       | (Auth Verify)  |       | (Auth Verify)  |
+----------------+       +----------------+       +----------------+
       |                        |                        |
       v                        v                        v
   Database A               Database B               Database C
       ^                        ^                        ^
       |                        |                        |
     Cache A                 Cache B                  Cache C

Components

User

user

Initiates requests with JWT token

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Entry point for requests; validates JWT token and forwards requests to microservices

Service A

service

First microservice that verifies JWT token and processes request

Service B

service

Second microservice that receives JWT token from Service A and verifies it

Service C

service

Third microservice that receives JWT token from Service B and verifies it

Database A

database

Stores data for Service A

Database B

database

Stores data for Service B

Database C

database

Stores data for Service C

Cache A

cache

Caches frequent queries for Service A

Cache B

cache

Caches frequent queries for Service B

Cache C

cache

Caches frequent queries for Service C

Request Flow - 17 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Service A

Service A → Cache A

Cache A → Service A

Service A → Database A

Service A → Service B

Service B → Service B

Service B → Cache B

Cache B → Service B

Service B → Database B

Service B → Service C

Service C → Service C

Service C → Cache C

Cache C → Service C

Service C → Database C

Service C → User

Failure Scenario

Component Fails:API Gateway

Impact:All incoming requests fail to be authenticated and routed, causing service unavailability.

Mitigation:Deploy multiple API Gateway instances behind the load balancer for redundancy and failover.

Architecture Quiz - 3 Questions

Which component is responsible for initially validating the JWT token?

A Service C

B Load Balancer

C API Gateway

D Cache A

Design Principle

This architecture shows how JWT tokens are propagated and verified at each microservice to maintain secure, stateless authentication. Using an API Gateway centralizes initial token validation, while each service re-verifies tokens to ensure trust. Caches reduce database load, and load balancers provide scalability and fault tolerance.

Practice

1. What is the main purpose of JWT token propagation in a microservices architecture?

easy

A. To encrypt all communication between microservices

B. To store user data permanently in each microservice

C. To securely share user identity information across multiple services

D. To replace API keys for service-to-service authentication

Solution

1. Step 1: Understand JWT token role

   JWT tokens carry user identity and claims securely in a compact form.

2. Step 2: Identify propagation purpose

   Propagating JWT tokens allows each microservice to verify and trust the user's identity without storing it locally.

3. Final Answer:

   To securely share user identity information across multiple services -> Option C

4. Quick Check:

   JWT propagation = share identity securely [OK]

Hint: JWT tokens carry user identity for trust across services [OK]

Common Mistakes:

• Confusing JWT propagation with data storage
• Thinking JWT encrypts all communication
• Assuming JWT replaces all authentication methods

2. Which HTTP header is commonly used to forward the JWT token between microservices?

easy

A. Authorization

B. X-Auth-Token

C. Cookie

D. Content-Type

Solution

1. Step 1: Identify standard header for tokens

   The Authorization header is the standard way to send bearer tokens like JWT in HTTP requests.

2. Step 2: Confirm other headers' roles

   X-Auth-Token is less standard, Cookie is for browser sessions, Content-Type defines data format.

3. Final Answer:

   Authorization -> Option A

4. Quick Check:

   JWT token sent in Authorization header [OK]

Hint: JWT tokens go in Authorization header as Bearer [OK]

Common Mistakes:

• Using Cookie header for token forwarding
• Confusing Content-Type with authentication headers
• Assuming custom headers like X-Auth-Token are standard

3. Consider this code snippet in a microservice forwarding a JWT token:

fetch('http://serviceB/api', {
  headers: { 'Authorization': req.headers['authorization'] }
})

What will happen if the original request has no Authorization header?

medium

A. The Authorization header is set to an empty string

B. Service B receives an Authorization header with value 'undefined'

C. The fetch call throws an error and fails

D. Service B receives the request without any Authorization header

Solution

1. Step 1: Check header forwarding code

   The code forwards req.headers['authorization'] directly as the Authorization header value.

2. Step 2: Understand missing header behavior

   If req.headers['authorization'] is undefined, the header is omitted in fetch, so Service B gets no Authorization header.

3. Final Answer:

   Service B receives the request without any Authorization header -> Option D

4. Quick Check:

   Missing header means no Authorization sent [OK]

Hint: Undefined header means no header sent, not 'undefined' string [OK]

Common Mistakes:

• Assuming 'undefined' string is sent as header value
• Expecting fetch to throw error on missing header
• Thinking header is set to empty string automatically

4. A microservice fails to verify JWT tokens from upstream services. Which of these is the most likely cause?

medium

A. The microservice does not forward the Authorization header

B. The microservice uses a different secret or public key to verify tokens

C. The microservice sends tokens in the request body instead of headers

D. The microservice caches tokens for too long

Solution

1. Step 1: Analyze verification failure causes

   Verification fails if the microservice uses a wrong secret or public key to check the JWT signature.

2. Step 2: Evaluate other options

   Not forwarding headers causes downstream issues, sending tokens in body is non-standard but not verification failure, caching affects freshness but not signature verification.

3. Final Answer:

   The microservice uses a different secret or public key to verify tokens -> Option B

4. Quick Check:

   Wrong key = verification fails [OK]

Hint: Verification needs matching secret/public key [OK]

Common Mistakes:

• Confusing forwarding issues with verification errors
• Assuming token location affects signature verification
• Ignoring key mismatch as cause of failure

5. In a microservices system, Service A receives a JWT token from a user and calls Service B, which calls Service C. To ensure secure JWT token propagation and verification, which design is best?

hard

A. Service A sends the JWT to Service B, which forwards the same JWT to Service C; each service verifies the token locally

B. Service A sends the JWT to Service B; Service B generates a new token for Service C with its own secret

C. Service A sends the JWT only to Service B; Service B calls Service C without any token

D. Service A sends the JWT to Service B; Service B stores the token and Service C fetches it from Service B when needed

Solution

1. Step 1: Understand token propagation best practice

   JWT tokens should be forwarded unchanged so each service can verify the original user identity and claims.

2. Step 2: Evaluate alternatives

   Generating new tokens breaks trust chain; skipping tokens breaks authentication; fetching tokens from another service adds complexity and risk.

3. Final Answer:

   Service A sends the JWT to Service B, which forwards the same JWT to Service C; each service verifies the token locally -> Option A

4. Quick Check:

   Forward original JWT for trust and verification [OK]

Hint: Forward original JWT unchanged for trust across services [OK]

Common Mistakes:

• Creating new tokens at intermediate services
• Not forwarding tokens to all downstream services
• Relying on token fetching instead of forwarding