Where Should JWT Tokens Be Validated in Microservices?

JWT tokens should generally be validated at every service that treats the token as proof of identity, not only at the API Gateway.

A strong microservices design is:

Client
   |
   | JWT
   v
API Gateway
   |
   | Validate JWT
   v
Order Service
   |
   | Validate JWT
   | Authorize request
   v
Controller

The key principle is:

The API Gateway can validate JWT centrally, but each microservice should protect its own endpoints and enforce its own authorization.

1. Why Validate at the API Gateway?

The gateway is the public entry point:

Internet
   |
   v
API Gateway
   |
   +----> Product Service
   +----> Order Service
   +----> Payment Service

Validating there allows invalid requests to be rejected early:

Client
   |
   | Invalid / Expired JWT
   v
Gateway
   |
   X
401 Unauthorized

This prevents obviously unauthorized traffic from reaching downstream services.

Gateway responsibilities commonly include

• token validation/authentication
• routing
• rate limiting
• TLS termination
• request-size restrictions
• centralized logging/observability

2. Why Validate Again in the Microservice?

Suppose JWT validation exists only at the gateway:

Client
   |
   | JWT
   v
Gateway
   |
   | Valid
   v
Order Service

Order Service assumes:

"If the request reached me, it must be trusted."

That becomes dangerous if someone can bypass the gateway:

Compromised Internal Service
           |
           | Direct request
           v
      Order Service
           |
           v
       Controller

If Order Service has no authentication/authorization protection, the gateway's security has been bypassed.

Therefore defense in depth is preferable:

                    Internet
                       |
                       v
                API Gateway
                       |
                Validate JWT
                       |
                       v
                 Order Service
                       |
                Validate identity
                       |
                  Authorize
                       |
                       v
                  Controller

3. What Should the Microservice Validate?

If the microservice receives a JWT directly, it should validate the token according to its trust configuration, including:

Signature
   +
Issuer
   +
Audience
   +
Expiration
   +
Not Before

Then authorization evaluates:

Scopes
Permissions
Roles
Claims

So the complete process is:

JWT
 |
 v
Authentication
 |
 +-- Signature valid?
 +-- Issuer trusted?
 +-- Audience correct?
 +-- Token still valid?
 |
 v
ClaimsPrincipal
 |
 v
Authorization
 |
 +-- Required permission?
 +-- Required scope?
 +-- Required role?
 |
 v
Controller

4. Example ASP.NET Core Microservice

Install/configure JWT Bearer authentication as appropriate:

dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

appsettings.json

{
  "Authentication": {
    "Authority": "https://identity.example.com",
    "Audience": "order-api"
  }
}

Program.cs

using Microsoft.AspNetCore.Authentication.JwtBearer;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority =
            builder.Configuration["Authentication:Authority"];

        options.Audience =
            builder.Configuration["Authentication:Audience"];

        options.RequireHttpsMetadata = true;
    });

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ReadOrders", policy =>
    {
        policy.RequireAuthenticatedUser();
        policy.RequireClaim("permission", "orders.read");
    });
});

var app = builder.Build();

app.UseHttpsRedirection();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

app.Run();

Controller:

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/orders")]
[Authorize]
public class OrdersController : ControllerBase
{
    [HttpGet]
    [Authorize(Policy = "ReadOrders")]
    public IActionResult GetOrders()
    {
        return Ok(new[]
        {
            new
            {
                Id = 1001,
                Product = "Laptop"
            }
        });
    }
}

Now even if someone reaches Order Service directly:

Direct Request
      |
      | No JWT
      v
Order Service
      |
      X
401 Unauthorized

5. Gateway Validation vs Microservice Authorization

There is an important distinction.

API Gateway

Can perform coarse-grained authentication:

Is this a valid token?
Is it issued by our trusted issuer?
Is it intended for this API surface?

Microservice

Should perform resource-specific authorization:

Can this caller read orders?
Can this caller create an order?
Can this caller cancel this particular order?

For example:

JWT

permission:
    orders.read

Order Service:

[Authorize(Policy = "ReadOrders")]

Payment Service might instead require:

payments.process

6. Do We Always Need to Perform JWT Validation Twice?

Not necessarily in exactly the same way.

There are architectures where the gateway authenticates the external JWT and downstream services trust a different authenticated identity mechanism, such as:

• mTLS
• service mesh identity
• workload identity
• a gateway-issued/internal credential
• token exchange

For example:

External Client
      |
      | User JWT
      v
API Gateway
      |
      | Validate JWT
      |
      | Authenticated internal identity
      v
Order Service

The important requirement is not:

"Every component must literally parse the same JWT."

It is:

A microservice must not blindly trust unauthenticated requests simply because they came from the internal network.

7. Service-to-Service Calls

Consider:

Client
   |
   | User JWT
   v
Gateway
   |
   v
Order Service
   |
   | ?
   v
Payment Service

Do not automatically assume that the original user's JWT should be forwarded to every downstream service.

Payment Service may instead expect a token representing Order Service:

Order Service
     |
     | Client Credentials /
     | Workload Identity
     v
Authorization Server
     |
     | Service Access Token
     v
Order Service
     |
     | Bearer Service Token
     v
Payment Service
     |
     | Validate Token
     | Check payments.process
     v
Process Payment

This clearly establishes:

Caller = Order Service
Permission = payments.process

8. Recommended Architecture

For many production systems:

                Identity Provider
                       |
                  Issues JWT
                       |
                       v
Client ------------> Gateway
                       |
                 Authenticate
                 Rate Limit
                 Route
                       |
                       v
                Order Service
                       |
              Authenticate identity
              Authorize orders.*
                       |
                       |
                 Service Token
                       |
                       v
               Payment Service
                       |
              Authenticate identity
              Authorize payments.*
                       |
                       v
                 Payment DB

Also restrict network connectivity so services cannot be unnecessarily reached directly.

Advantages

Validating identity at appropriate trust boundaries provides:

• Defense in depth
• Protection against gateway bypass
• Better service isolation
• Zero-Trust-oriented architecture
• Independent service authorization
• Reduced lateral-movement risk
• Clearer security boundaries

Disadvantages

It introduces:

• additional configuration
• some token-validation overhead
• signing-key/metadata management
• more complex service-to-service authentication
• more authorization policies to maintain

However, these costs are normally justified for security-sensitive distributed systems.

Key Points

For interviews, remember:

Identity Provider
      |
      | Issues JWT
      v
Client
      |
      | JWT
      v
API Gateway
      |
      | Authenticate / reject bad token
      v
Microservice
      |
      | Authenticate trusted identity
      | Authorize resource operation
      v
Controller

Most important points:

1. The Identity Provider issues the JWT.
2. The Gateway can validate external JWTs.
3. A microservice should not blindly trust requests because they came through the internal network.
4. If a microservice consumes the JWT as proof of identity, it should validate it.
5. The microservice should always enforce its own authorization rules.
6. Service-to-service calls may use separate service tokens/workload identities rather than forwarding the user's JWT.
7. Network isolation complements authentication; it does not replace it.

Interview Questions & Answers

Q1. Where should JWT be validated in Microservices?

Answer:

JWT can be validated at the API Gateway to reject invalid external requests early. If downstream microservices consume the JWT as proof of identity, they should also validate it and enforce their own authorization policies. Alternatively, the gateway can authenticate the external JWT and downstream services can use another trusted workload identity mechanism.

Q2. Is validating JWT only at the API Gateway enough?

Answer:

It can create a security dependency on the gateway and network boundary. A stronger design ensures downstream services also authenticate trusted identities and enforce their own authorization, so direct internal access does not automatically bypass security.

Q3. Why validate at both Gateway and Microservice?

Answer:

The gateway provides centralized edge protection, while the microservice protects the resource it owns. This provides defense in depth.

Q4. Does every Microservice need JWT authentication?

Answer:

Not necessarily JWT specifically. Every protected service should have an appropriate mechanism for establishing trusted caller identity. That might be JWT bearer authentication, workload identity, mTLS, or service-mesh identity.

Q5. Should the same user JWT be forwarded between all Microservices?

Answer:

No. Forward it only when delegation is intentional and the downstream API is an appropriate audience. For machine-to-machine communication, a dedicated service identity or Client Credentials access token is often more appropriate.

Short Interview Answer

JWT tokens are commonly validated at the API Gateway to reject invalid external requests early. However, security should not exist only at the gateway. If a microservice receives and relies on the JWT, it should validate the token and enforce its own authorization policies. For service-to-service communication, we may use dedicated service tokens, workload identity, or mTLS instead of blindly forwarding the user's JWT. This provides defense in depth and prevents gateway bypass from becoming an authentication bypass.