Why Token Pass‑Through Is Bad and Better Alternatives for Secure Microservice Calls

Token Pass‑Through (Not Recommended)

Passing the original user token between microservices may simplify code but mixes internal and external APIs, making them hard to distinguish and violating stateless design principles needed for atomic, reusable methods.

Problems

Internal and external APIs become indistinguishable.

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

Consider three scenarios: user sign‑in adds points, admin manually adds points, and a distributed scheduler batch adds points. If the points‑adding API relies on the current logged‑in user ID, the admin scenario forces a separate API, reducing reuse.

Solution : Do not transmit the token; explicitly pass required parameters such as userId from the gateway to downstream services. /api/inside/** – define internal API paths and reject them at the gateway.

Unified Authorization via Gateway

Centralize authentication and authorization in the application gateway. After verification, the gateway injects user information (e.g., userId) into request headers for downstream services, eliminating the need for each service to parse the token.

Feign Internal Call

Combine Spring Cloud Gateway with Feign for internal calls. The gateway performs unified authentication, then forwards the authenticated data in headers.

Drawback : Service B must expose a dedicated internal controller for Feign to call, increasing code volume.

Dubbo Internal Call

Combine Spring Cloud Gateway with Dubbo. After the gateway authenticates the request, it forwards user data to downstream services via Dubbo.

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

Disadvantage : Slightly increases the complexity of the technology stack.

Spring Boot Web + Dubbo (No Gateway)

Replace the gateway with a Spring Boot Web application. Use Undertow (a non‑blocking container) instead of Tomcat to achieve comparable throughput.

All service controllers are integrated into the Web app via dependencies, or each service can provide its own controller module while the Web app only contains a starter class.

Pros : Simplified architecture; only service code remains. Performance testing does not need to consider the gateway thread pool, focusing solely on Dubbo thread pools.

Cons : Routing cannot be adjusted dynamically through a configuration center; adding a new service requires redeploying the Web app.

Non‑Unified Authorization

Each microservice implements its own authentication logic, or a shared JAR can be used to standardize auth across services without involving the gateway.

Regular Mode (Common Auth Module)

Develop a reusable authentication module that every service can integrate. The module provides:

JWT token parsing.

Permission‑check interceptors.

Caching (local cache or Redis).

This approach suits large projects where different teams own separate microservices but share the same permission data.

Integration with Kubernetes

Replace the application gateway with a K8s Ingress gateway. Use K8s Service for load balancing and service discovery, eliminating the need for a separate registry.

Example service URLs:

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

dubbo://goods-svc:20880

This reduces deployment complexity and removes an unnecessary forwarding layer.

Conclusion : No single pattern is universally correct; select the approach that best matches your project's requirements and constraints.