Why Token Pass‑Through Is Discouraged and Alternative Unified Authorization Designs for Microservices

When first learning microservices, many online solutions suggest token pass‑through for authentication, but this approach mixes internal and external APIs, reduces statelessness, and harms code reuse.

Instead, the gateway should parse the JWT token, extract the userId, and forward it as an explicit request parameter to downstream services, ensuring each service remains stateless and its APIs are reusable across scenarios such as user sign‑in, admin‑added points, and batch scheduling.

Internal APIs should be isolated from external exposure, for example using a path prefix like /api/inside/** and rejecting external calls at the gateway layer.

Unified authorization centralizes authentication in the application gateway, which can be combined with different internal‑call mechanisms:

Feign internal call: Spring Cloud Gateway + Feign, adds authentication info to request headers after the gateway validates the token. Drawback: each service needs a separate controller for internal calls.

Dubbo internal call: Spring Cloud Gateway + Dubbo, avoids extra controllers and keeps code concise, but adds complexity to the technology stack.

Spring Boot Web only: Removes the gateway, uses a single Spring Boot Web project (preferably with Undertow for non‑blocking I/O) to host all controllers, and performs unified authentication there. This simplifies the structure but loses dynamic routing via configuration.

For non‑unified authorization, each service implements its own auth module (JWT parsing, permission interception, caching) while the gateway only performs routing.

When deploying to Kubernetes, the gateway can be replaced by an Ingress, and services can be addressed directly via Kubernetes Service DNS names, e.g., http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880, eliminating the need for a separate service registry.

Ultimately, the choice of architecture depends on project size, team structure, and operational requirements; there is no universally correct solution.