Token Transmission and Internal Service Calls in Spring Cloud Microservices

When first learning microservices, many online solutions suggest token pass‑through for authentication. This article argues that passing the token to every downstream service is not a good design.

Reasons: internal APIs become indistinguishable from external ones, and internal services should be stateless to keep methods atomic and reusable.

Instead, the gateway should validate the token, extract the userId, and pass it explicitly as a parameter to downstream services. This improves code reuse across scenarios such as user sign‑in, admin manual credit addition, and batch scheduled credit updates.

Unified authentication is achieved by placing the auth logic in the application gateway. After verification, the gateway adds headers (e.g., userId) to the request.

Three internal‑call patterns are described:

Feign: Spring Cloud Gateway + Feign, but each target service needs a dedicated internal controller.

Dubbo: Spring Cloud Gateway + Dubbo, no extra controller required, but adds complexity to the tech stack.

Spring Boot Web + Dubbo: removes the gateway, uses an Undertow container for non‑blocking I/O, and aggregates all service controllers in a single web project.

Regular mode recommends a shared authentication module providing JWT parsing, permission interception, and caching (local or Redis). This suits large teams where each microservice maintains its own permission rules.

Integration with Kubernetes replaces the gateway with an Ingress and uses K8S Service for service discovery, eliminating the need for a separate registry. Example internal API path and service URLs:

/api/inside/**

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

dubbo://goods-svc:20880

The choice of architecture depends on project requirements; there is no universally correct solution.