Tenant Isolation via NGINX Auth Gateway: No Default Tenant

The article explains how a multi‑tenant platform enforces tenant identity at the NGINX layer before the Auth Service is even invoked. Two inputs are accepted: an explicit X‑Tenant‑ID header for service‑to‑service calls and an implicit host header mapped via X‑Tenant‑Host for per‑tenant DNS such as tenant1.example.com. There is no fallback to a default tenant; if both inputs are missing, NGINX returns a 400 error before the Auth Service runs. Tenant identity is pinned at SNI time with per‑tenant server blocks, allowing per‑tenant TLS certificates and eliminating ambiguity. The default tenant was removed after 90 days and never re‑introduced. The configuration uses a single if‑block hierarchy: header priority over host, and a hard 400 if neither is present. The auth_request subrequest is then forwarded with the resolved tenant ID.

This strict approach prevents cross‑tenant data leaks and simplifies debugging because every request carries a clear tenant context. The article also highlights the importance of keeping the NGINX config in sync with the Auth Service’s tenant checks to avoid accidental fallback logic.

By enforcing explicit tenant resolution and removing the default tenant, the platform eliminates a common source of data leakage bugs and ensures that every request is correctly scoped from the very first hop.