Why Token Pass‑Through Fails: Better Strategies for Secure Microservice Authentication

Hello, I am a senior architect.

Token Pass‑Through (Not Recommended)

Passing the token to every microservice so they can obtain the current user information may be convenient but is a poor design.

Reasons

Internal APIs and external APIs become mixed and hard to distinguish.

Internal microservice APIs should be stateless to ensure atomicity and improve code reuse.

Scenarios

User sign‑in adds points.

Backend admin manually adds points for a user.

Distributed scheduler batch adds points.

When the API adds points based on the logged‑in user ID, scenario two (admin adds points) requires a separate API because the current login is an admin, not a user, reducing code reuse.

Do not pass the token; provide explicit parameters.

After the first service in the route parses and authenticates the token, it forwards the userId to downstream services, which no longer need to parse the token. A single API that accepts userId as a parameter satisfies all three scenarios and improves atomicity and reuse.

To prevent external access, internal APIs should be placed under a distinct path, e.g., /api/inside/**, and blocked at the gateway.

Unified Authentication

Centralize API authentication in the application gateway. After authentication, the gateway adds user information (e.g., userId) to request headers for downstream services.

Feign Internal Call

Spring Cloud Gateway + Feign internal calls concentrate authentication at the gateway and forward authenticated data via headers.

Advantages: Clear separation of internal and external APIs.

Disadvantages: Each service needs a dedicated controller for Feign to call, increasing code volume.

Dubbo Internal Call

Spring Cloud Gateway + Dubbo internal calls also centralize authentication, forwarding userId in headers.

Advantages: No extra controller is required; only local service and remote Dubbo service differ, resulting in cleaner code.

Disadvantages: Slightly increases the technology stack complexity.

Spring Boot Web + Dubbo (No Gateway)

Remove the gateway and use a Spring Boot Web project (preferably with Undertow, a non‑blocking container) to handle authentication and forward userId.

All service controllers are integrated into this web application; the gateway service only contains a starter class and depends on each service’s controller module.

Advantages: Simplifies project structure; only service code remains, and performance testing only needs to consider Dubbo thread pools.

Disadvantages: Cannot dynamically adjust routing via a configuration center; adding a new service requires redeployment.

Non‑Unified Authentication

Each service implements its own authentication or shares a common auth module that provides:

JWT token parsing.

Permission interception.

Caching (local or Redis).

This model suits large projects where each microservice is owned by a separate team, allowing independent permission rule maintenance while keeping the rule data unified.

Integration with Kubernetes

When deploying to K8S, the application gateway can be replaced by the K8S Ingress gateway, eliminating the need for a separate service registry. Services are accessed via K8S Service DNS names, e.g.:

http://goods-svc:8080/api/goods/info/10001

dubbo://goods-svc:20880

This reduces an extra routing layer and leverages K8S Service load balancing.

There is no universally correct solution; choose the approach that best fits your project's requirements.