Why Do Microservices Still Need Internal Authorization After Gateway Authentication?

Authentication vs Authorization in Microservices

The gateway performs unified authentication: it validates the token, extracts the user identity, and forwards it downstream via HTTP headers. Microservices perform business‑level authorization: they check whether the authenticated user has permission to operate on specific resources, such as modifying an order.

Internal Network Is Not Implicitly Secure

Assuming the internal network is safe introduces three common risks:

Horizontal movement

If an attacker compromises an external‑facing microservice, they can obtain a server inside the private network and, because services trust each other, directly call sensitive endpoints such as http://order-service/delete?id=xxx, bypassing the gateway.

SSRF attacks

A publicly exposed microservice with an SSRF flaw can be tricked into sending forged requests to other internal services; without a second authentication check, the downstream service will execute the request unconditionally.

Insider mistakes and ops errors

Developers or operators may bypass the gateway during debugging or misconfigure service addresses, leading to accidental data deletion.

Consequently, modern microservice security adopts a zero‑trust model: every request and every node must be re‑authenticated and authorized, even inside the private network.

Why Business Authorization Should Not Be Handled by the Gateway

Embedding fine‑grained business authorization in the gateway creates two major problems:

Severe business coupling

To decide whether user A can modify order B, the gateway would need to understand order‑service business logic, query the order database, check ownership, and consider order status. This collapses the microservice’s independent responsibilities into a monolithic gateway.

Gateway performance degradation

Gateways built on asynchronous, non‑blocking frameworks like Netty (e.g., Spring Cloud Gateway) would suffer from heavy thread‑pool usage and increased latency if they performed numerous business‑database queries, dramatically reducing overall ingress throughput.

Common Industry Practice

Most architectures adopt a two‑layer approach:

Gateway layer – coarse‑grained authentication and context propagation

The gateway validates the token, extracts core user context such as userId, tenantId, and roles, and forwards it via an HTTP header (e.g., X-User-Context).

X-User-Context: {
  "userId": "10001",
  "userName": "小富",
  "roles": ["ADMIN"]
}

Microservice layer – fine‑grained authorization and business validation

Each service uses an interceptor or filter to read X-User-Context, bind it to the thread context, and then performs role checks and data‑ownership verification in the business code. A typical Spring Boot controller:

@RestController
@RequestMapping("/orders")
public class OrderController {
    @Autowired
    private OrderService orderService;

    // 1. Role check via Spring Security
    @PutMapping("/{orderId}")
    @PreAuthorize("hasAuthority('ORDER_WRITE')")
    public ResponseEntity<Void> updateOrder(@PathVariable Long orderId, @RequestBody OrderDto orderDto) {
        // 2. Get user ID from ThreadLocal
        Long currentUserId = UserContextHolder.getUserId();

        // 3. Data ownership check
        Order order = orderService.getById(orderId);
        if (order == null) {
            return ResponseEntity.notFound().build();
        }
        if (!order.getUserId().equals(currentUserId)) {
            // 4. Reject if owner mismatch
            throw new AccessDeniedException("您无权修改该订单！");
        }

        orderService.update(orderId, orderDto);
        return ResponseEntity.ok().build();
    }
}

This code separates identity parsing (interceptor) from role checks (Spring Security) and data‑ownership validation (business logic), keeping the gateway lightweight.

Propagating User Context in Internal Calls

When one microservice calls another (e.g., Service A uses Feign to call Service B), the user context must be passed along. A common solution is a Feign RequestInterceptor that injects the X-User-Context header from a ThreadLocal holder.

Feign interceptor to propagate user context

@Component
public class FeignAuthInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        // Retrieve user context from ThreadLocal
        String userContextJson = UserContextHolder.getRawContext();
        if (userContextJson != null) {
            // Automatically add to Feign request header
            template.header("X-User-Context", userContextJson);
        }
    }
}

Internal trust and anti‑spoofing measures

Lightweight symmetric HMAC‑SHA256 signing : the gateway signs the user context with a shared secret and a timestamp; services verify the signature and expiry, offering high performance compared to RSA.

Private‑network whitelist : network or security‑group rules allow only the gateway IP range or internal K8s pod CIDR to reach services; external IPs are rejected.

Service‑mesh mutual TLS : with Istio or similar, all inter‑service traffic is encrypted and authenticated by Envoy sidecars, eliminating the need for application‑level anti‑spoofing.

Summary

The security boundary in a microservice system is: the gateway protects the outside world, while each microservice protects the inside. Implementing a second‑level authorization adds boilerplate but is essential for a stable production system. The logic can be encapsulated in a common interceptor or starter library, allowing developers to retrieve the user ID from context with minimal impact on business code.