Token Transmission and Unified Authorization Strategies in Microservices

1. Token

1.1 Token Pass‑through (Not Recommended)

When first learning microservices, many online solutions use token pass‑through for authentication, but this design is not ideal. Passing the token allows each microservice to obtain the current user information, which may be convenient for coding but leads to poor design.

Reason 1: Internal APIs and external APIs are mixed together, making them hard to distinguish.

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

In other words, Service B should not care about the login state when providing an API; the first service in the routing layer should verify the login state and forward the necessary parameters (e.g., userId) to downstream services.

Scenario 1: User signs in and receives points.

Scenario 2: Backend admin manually adds points to a user.

Scenario 3: Distributed scheduler batch adds points to many users.

If the points service provides an API that adds points based on the currently logged‑in user ID, scenario 2 would require a separate API because the logged‑in entity is the admin, not the target user, reducing code reuse.

1.2 Explicit Parameter Passing (Recommended)

The first service in the routing layer parses and authenticates the token, then explicitly passes the userId to downstream services. Subsequent services no longer need to parse the token. With this approach, a single API that accepts userId can handle all three scenarios, ensuring atomicity and higher code reuse.

Note: The provided internal APIs should not be exposed to the external network. Define internal API path rules such as /api/inside/** and reject external requests at the gateway layer.

2. Unified Authorization

Unified authorization means centralizing API authentication in the application gateway.

2.1 Feign Internal Call

Spring Cloud Gateway + Feign internal call: authentication is performed at the gateway, and after verification the gateway adds authentication information (e.g., userId) to request headers for downstream services.

Drawback: Service A must create a separate internal Controller interface for Service B so that Feign can call it, increasing code volume. 2.2 Dubbo Internal Call Spring Cloud Gateway + Dubbo internal call: authentication is also centralized at the gateway, and the gateway forwards authentication data via request headers. Advantage: No need to write an extra Controller; only local service and remote DubboService differ, making the code simpler. Drawback: Slightly increases the complexity of the technology stack. 2.3 Spring Boot Web + Dubbo Internal Call This design removes the gateway and uses a Spring Boot Web project to replace it. The Web container should be switched to Undertow (non‑blocking) for better throughput, although Tomcat can still work. Because the gateway is removed, all service Controllers need to be integrated into the Web application, and the unified authentication/authorization logic resides there. Each service can still maintain its own Controller module, and the gateway project only needs a starter class that depends on all service Controllers. Advantages: Simplifies project structure; only service code remains. Performance testing only needs to consider Dubbo thread pools, not gateway thread pools. Drawbacks: Cannot dynamically adjust routing via a configuration center; adding a new service requires redeploying the Web application. 3. Non‑Unified Authorization In this mode the gateway only performs routing without authentication; each service implements its own authentication, possibly sharing a common authentication library. 3.1 Conventional Mode Develop a generic authentication module that each service integrates, providing JWT parsing, permission interception, and caching (local or Redis). This suits large projects where each microservice is owned by a different team, allowing independent permission rule maintenance. When deploying on Kubernetes, the lightweight gateway can be replaced by an Ingress gateway, simplifying deployment. 3.2 Integration with K8S Replace the application gateway with a Kubernetes Ingress gateway. The Ingress forwards traffic to services directly, eliminating the need for a separate service registry and reducing an extra forwarding layer. Service calls can use DNS‑like names, e.g. http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880 . Feign Example @FeignClient(name = "user-service", url = "http://goods-svc:8080") public interface UserServiceClient { @GetMapping("/users/{id}") User getUserById(@PathVariable("id") Long id); } Dubbo Example @Reference(url = "dubbo://goods-svc:20880") private DemoService demoService; The article concludes that there is no universally correct solution; the choice depends on project requirements and team preferences.