Why Token Pass‑through Is Discouraged in Microservice Authentication and Alternative Design Patterns

When first learning microservices, many online solutions suggest passing the token for authentication, but the author argues this design is flawed.

Reasons include mixing internal and external APIs, and the need for stateless internal services to maintain atomicity and improve code reuse.

Instead of relying on token pass‑through, the author recommends that the first service in the request chain parses the token, extracts the userId, and passes it explicitly to downstream services, ensuring each service remains unaware of login state.

Unified Authorization : Centralize API authentication in the application gateway, which validates the token and injects user information into request headers for subsequent services.

Implementation options:

Feign internal calls: /api/inside/** pattern is used to distinguish internal APIs, with the gateway handling authentication.

Dubbo internal calls: Direct service-to-service communication without extra controller interfaces, simplifying code.

Spring Boot Web without a gateway: Use Undertow for non‑blocking I/O, integrate all service controllers into a single web application, and handle authentication centrally.

For Kubernetes deployments, the gateway can be replaced by an Ingress, and services can be addressed directly via Kubernetes Service DNS, e.g., http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880 .

The author emphasizes that there is no universally correct solution; the best choice depends on the project's needs.

Finally, the author invites readers to join a technical community offering ChatGPT accounts, AI‑related content, and various side‑project resources, highlighting promotional offers and a limited‑time discount.