Best Practices for Internal Service Calls and Token Handling in Microservices

When building microservices, passing the original authentication token to downstream services (token‑pass‑through) is discouraged because it mixes internal and external APIs, reduces statelessness, and lowers code reuse.

Instead, the gateway should authenticate the request, extract the user ID, and forward only the necessary parameters, ensuring each service remains stateless and its API can be reused across scenarios such as user sign‑in, admin‑added points, or batch scheduling.

Unified Authorization centralizes authentication in the application gateway, which validates the token and injects user information (e.g., /api/inside/** ) into request headers for downstream services.

Feign Internal Call

Spring Cloud Gateway combined with Feign places the authentication logic in the gateway and forwards the user ID via request headers, but each downstream service must expose a dedicated internal controller, increasing code volume.

Dubbo Internal Call

Using Spring Cloud Gateway with Dubbo also forwards authenticated user data, but it avoids the extra internal controller because Dubbo services are invoked directly through remote interfaces, resulting in cleaner code at the cost of a slightly more complex technology stack.

Spring Boot Web + Dubbo

This approach removes the gateway entirely, using a Spring Boot Web application (preferably with the non‑blocking Undertow container) to host all service controllers and perform unified authentication. It simplifies the architecture and improves performance, though dynamic routing via a configuration center becomes unavailable.

Non‑Unified Authorization

When the gateway does not handle authentication, each service implements its own auth logic, or a shared JAR can be used to standardize the process.

Regular Mode

A generic authentication module can be shared across services, providing JWT parsing, permission interception, and caching (local or Redis). This model suits large teams where each service team maintains its own permission data while following a common rule set.

Kubernetes Integration

Replacing the gateway with a K8s Ingress and leveraging K8s Service load‑balancing eliminates the need for a separate service registry. Services can be addressed directly, e.g., http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880 , reducing deployment complexity.

Ultimately, there is no universally correct solution; the best choice depends on the specific project requirements and constraints.