Bird
Raised Fist0
Microservicessystem_design~3 mins

Why JWT token propagation in Microservices? - Purpose & Use Cases

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

What if your app could remember who you are perfectly, no matter how many services it talks to?

The Scenario

Imagine you have a chain of friends passing secret notes to each other. Each friend must read the note, remember the secret, and then whisper it to the next friend. If one forgets or changes the secret, the whole chain breaks.

The Problem

Manually passing authentication info between services is slow and risky. Each service must remember and verify the user's identity separately, leading to mistakes, delays, and security holes. It's like playing a long game of telephone where messages get lost or changed.

The Solution

JWT token propagation hands each service a sealed, tamper-proof token carrying the user's identity and permissions. Services just check the token instead of asking again. This keeps the chain strong, fast, and secure without extra back-and-forth.

Before vs After
Before
serviceA calls serviceB with user info stored in session
serviceB calls serviceC but must re-authenticate user
After
serviceA sends JWT token in request header
serviceB and serviceC verify token directly without extra calls
What It Enables

It enables seamless, secure user identity sharing across multiple services without repeated logins or slow checks.

Real Life Example

When you log into an online store, JWT token propagation lets the payment service, shipping service, and order tracking service all know who you are instantly and securely.

Key Takeaways

Manual identity sharing is slow and error-prone.

JWT tokens carry user info securely between services.

This makes multi-service apps faster and safer.

Practice

(1/5)
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