Spring Cloud Gateway tenant routing: authenticate at the edge and enforce again at the service

Route without elevating input

Do not turn an untrusted X-Tenant header into the identity used by downstream SQL. The edge can validate a token and forward a protected identity signal, but the receipt service should validate its own accepted credential or a carefully scoped internal assertion and check the tenant predicate itself. The tenant command path shows where the data rule belongs.

Keep rate limits and fallback scoped

A global IP bucket can punish users behind one proxy; a user-only bucket can let one tenant consume the full system. Choose a verified principal and tenant key, plus a bounded anonymous policy. A gateway retry of a POST can repeat a committed mutation. Test status, headers, route order and trusted-proxy behavior in a real gateway context; no Gateway starter is wired into the current source kit.

Boundary sketch

if (!verifiedPrincipal.tenantId().equals(requestedTenant)) {
    throw new AccessDeniedException("tenant mismatch");
}
return receiptRepository.findByTenantIdAndId(
    verifiedPrincipal.tenantId(), receiptId);

Cost and verification

Gateway filters add a hop and per-request checks. Distributed rate limits need shared state and failure policy; local buckets cannot enforce one global quota across replicas. This sketch is not executed by the current Spring source kit; verify it against the chosen dependencies and deployment.

Common Mistakes

• Do not trust a client-provided tenant header.
• Do not use the gateway as the only authorization layer.
• Do not configure a write-route retry without durable replay control.

Read next

Spring Boot tenant command API project: assemble the local write path, Spring method authorization: reject a cross-tenant read, Spring Cloud client retries: distinguish a safe read from an uncertain write, Spring Security filter chain: authentication, CSRF and request order.