Why Token Passing Is a Bad Idea and Better Alternatives for Microservice Calls

Token Passthrough (Not Recommended)

When first learning microservices, many solutions use token passthrough for authentication, but this design is problematic.

Reasons: mixing internal and external APIs makes distinction difficult; internal APIs should be stateless to ensure atomicity and improve code reuse.

Instead of relying on the token to identify the user, the first service (gateway) should parse the token, extract the userId, and pass it explicitly to downstream services.

Example scenarios: user sign‑in adds points, admin manually adds points, batch job adds points. If the API derives the userId from the token, the admin scenario requires a separate API, reducing reuse.

Do not pass data implicitly; provide explicit parameters.

Implementation: the gateway parses the token, forwards userId in request headers, and downstream services use the provided userId without re‑parsing the token.

Note: internal APIs must not be exposed to the external network; use a path rule such as /api/inside/** and block external access at the gateway.

Unified Authorization

Centralize API authentication at the application gateway, which validates the token and forwards authenticated information (e.g., userId) to downstream services.

Feign Internal Call Method

Spring Cloud Gateway + Feign internal calls perform unified authentication at the gateway and add authenticated information to request headers for downstream services.

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

Dubbo Internal Call Method

Spring Cloud Gateway + Dubbo internal calls also centralize authentication at the gateway and forward user information.

Advantages: No extra controller is needed; only local service and remote Dubbo service differ, making code simpler.

Drawback: Slightly increases the complexity of the technology stack.

Spring Boot Web + Dubbo Internal Call Method

This design removes the gateway and uses a Spring Boot Web project as a replacement. It should run on Undertow (a non‑blocking container) for performance.

All service controllers are integrated into the Web application, which handles unified authentication and authorization. Each service can provide its own controller module, and the gateway project only contains the startup class.

Pros: Simplifies project structure and avoids gateway thread‑pool considerations.

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

Non‑Unified Authorization

Each service implements its own authentication, or a shared JAR can provide a common auth module.

Regular Mode

A generic authentication module can be shared across services, offering JWT parsing, permission interception, and caching (local or Redis).

This mode suits large teams where each microservice is owned by a separate group, allowing each to maintain its own permission rules while sharing the same logic.

Integration with Kubernetes

Replace the application gateway with a Kubernetes Ingress gateway, removing the need for a separate registration center. Services can be accessed directly via K8s Service names, e.g., http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880.

This reduces deployment complexity and eliminates an extra forwarding layer.

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