Why Token Propagation Is Bad and How to Build Unified Auth for Microservices

Token Propagation (Not Recommended)

When first learning microservices, many solutions suggest propagating the token to obtain the current user information in downstream services. Although this can simplify code, it mixes internal and external APIs, making the design fragile.

Problem 1: Internal and external APIs become indistinguishable.

Problem 2: Internal services should not concern themselves with login status; authentication should be performed by the first service in the request chain, which then passes only the necessary parameters (e.g., userId) to downstream services.

Consider three scenarios:

User sign‑in adds points.

Admin manually adds points for a user.

Distributed scheduler batch adds points.

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

Pass Explicit Parameters Instead of Token

The first service (the gateway) parses and validates the token, extracts the userId, and forwards it in the request header. Downstream services no longer need to parse the token, improving atomicity and reusability.

Note: The internal API should not be exposed to the public internet; route paths must be distinguished to prevent external access.

Unified Authentication

Centralize authentication in an API gateway. The gateway validates the token, extracts user information, and adds it to request headers for downstream services.

Feign Internal Call

Using Spring Cloud Gateway together with Feign, the gateway performs unified authentication and forwards user data (e.g., userId) to subsequent services.

Pros:

No extra controller needed for internal calls; only local service vs. remote Dubbo service differs, resulting in cleaner code.

Cons:

Increases the overall technology stack complexity.

Spring Boot Web + Dubbo Internal Call

Replace the gateway with a Spring Boot Web project that directly handles authentication. Use Undertow (a non‑blocking container) instead of Tomcat to achieve similar throughput.

Cons:

Cannot dynamically adjust routes via a configuration center; adding a new service requires redeployment.

Non‑Unified Authentication

Each service implements its own authentication logic, optionally sharing a common library that provides:

JWT token parsing.

Permission interception.

Caching (local or Redis).

This approach suits large projects where each microservice is owned by a separate team, allowing independent permission rule maintenance while keeping the rule data unified.

Integration with Kubernetes

Replace the API gateway with a Kubernetes Ingress. Services communicate via Kubernetes Service objects, eliminating the need for a separate service registry.

Example service address: http://goods-bo://goods-svc:20880 Using Ingress and Service load‑balancing simplifies deployment and reduces an extra forwarding layer.

Choosing the Right Scheme

There is no universally correct solution; select the architecture that best fits your project's size, team structure, and operational requirements.