Why Token Pass‑Through Is Bad and How to Build Unified Auth in Microservices

Token Pass‑Through (Not Recommended)

When first learning microservices, many online solutions suggest passing the JWT token to downstream services for authentication. The author argues this design is flawed because it mixes internal and external APIs and breaks statelessness, reducing code reuse.

Reason 1: Internal APIs become indistinguishable from external ones.

Reason 2: Internal microservice APIs should remain stateless to ensure atomicity and higher reuse.

In practice, the first service in the request chain should validate the token, extract the userId, and pass that explicit parameter to downstream services. This avoids each service having to parse the token.

Scenario examples illustrate the problem:

Scenario 1: User signs in and earns points.

Scenario 2: Admin manually adds points for a user.

Scenario 3: Distributed scheduler batch adds points.

If the points‑adding API derives the userId from the token, scenario 2 requires a separate API because the logged‑in principal is the admin, not the target user, lowering reuse.

Solution: Do not transmit the token; instead provide explicit parameters such as userId.

Unified Authorization

Unified authorization means centralizing API authentication at the application gateway. The gateway parses the token, authenticates, and injects user information (e.g., userId) into request headers for downstream services.

Feign Internal Call

Spring Cloud Gateway + Feign internal calls: authentication is performed at the gateway, then userId is added to headers for downstream services.

Drawback: Service B must expose a separate internal controller for Feign, increasing code.

Dubbo Internal Call

Spring Cloud Gateway + Dubbo internal calls: similar authentication, but no extra controller is needed because Dubbo uses service interfaces directly.

Advantage: Cleaner code; only the local service vs remote DubboService differ.

Disadvantage: Slightly increases technology‑stack complexity.

Spring Boot Web + Dubbo (Gateway‑less)

Removing the gateway, a Spring Boot Web project replaces it. Use Undertow (non‑blocking) instead of Tomcat for higher throughput.

All service controllers are integrated into the web application; each service can provide its own controller module, and the gateway project only contains the main class and depends on those modules.

Pros: Simplified project structure, no need to consider gateway thread‑pool during performance testing; only Dubbo thread pools matter.

Cons: Cannot adjust routing dynamically via a configuration center; adding a new service requires redeploy.

Non‑Unified Authorization

In this mode, the gateway only forwards traffic; each service implements its own authentication, possibly sharing a common JWT library.

The common auth module provides JWT parsing, permission interception, and caching (local or Redis).

This approach suits large teams where each microservice is owned by a separate group, keeping permission rules centralized but enforcement local.

Kubernetes Integration

When the gateway is replaced by a K8s Ingress, service discovery can be handled by K8s Service objects, eliminating the need for a separate registry.

Example URLs:

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

dubbo://goods-svc:20880

The author emphasizes that no solution is universally right; the best choice matches the project's constraints.

Conclusion: Choose the authentication and routing pattern that aligns with your team size, technology stack, and operational requirements.