How OPPERIQ Enforces Tenant Isolation at Every Layer

Multi-tenancy is the assumption everything else in OPPERIQ is built on. One deployment serves many organisations, so a single query that forgets which organisation it belongs to is not a bug — it is a data breach. That risk is why isolation is handled in three places rather than one.

Three layers, one guarantee

• Middleware resolves the tenant from the verified JWT on every request and rejects requests belonging to a suspended tenant before any handler runs.
• A request-scoped tenant context exposes the tenant, the calling user and their role to every service method, so no service has to re-derive identity from the transport layer.
• The repository layer applies the tenant filter to reads and writes, which keeps the scoping decision in one place instead of scattered across hundreds of query call sites.

Platform administration runs on a separate authentication path entirely. Platform administrators provision and suspend tenants but cannot read tenant business data, and tenant administrators cannot reach platform routes. The two role systems never overlap.

Why we test isolation explicitly

Isolation enforced in application code is only as strong as the code paths that respect it, so we treat it as a testable property rather than a design intention. A dedicated suite attempts cross-tenant reads and writes against the API and asserts that each one fails, and it runs on every change to the data layer.

Being precise about the mechanism matters. Isolation is enforced by the application, not by database row-level security, which means the test suite and the single scoping choke point are what keep the guarantee honest as the schema grows.