Authentication, authorization, and tenant isolation

01Authentication, authorization, and tenant isolation: definitions

Authentication establishes who a caller is. Authorization decides whether that caller may perform a particular action on a particular resource. A tenant is a customer or organization whose users, data, and access policies are managed as one group; multi-tenancy means one service supports several tenants, often on shared infrastructure. Tenant isolation keeps one tenant’s users and workloads from improperly accessing or affecting another tenant’s data and resources.

Tenant isolation must hold across every path that returns data or creates an effect. For example, user U9 belongs to tenant Acme and may read invoice I17; user U10 belongs to Birch and has no such permission. Knowing I17 or copying its URL must not authorize access, including through search, exports, attachments, or background jobs.

A random identifier makes guessing harder; it does not establish permission. HTTPS protects a communication channel; it does not tell the application whether the caller owns the invoice. Building security into the request and data model gives each protection a specific job.

02Trusted principal, membership, roles, and revocation

A user may belong to multiple tenants. Switching from Acme to Birch requires a verified membership decision. A support administrator may have additional narrowly scoped privileges that should be explicit and auditable. Service-to-service identity similarly needs a bounded permission set; an internal network address is not sufficient authorization.

Limit credential permissions and lifetime, and decide how revocation takes effect. After a user is removed, a cached membership check may still allow access. Expire or invalidate that decision according to the maximum revocation delay the service promises.

Keep the mechanisms distinct:

A JSON Web Token (JWT) is a token format, not an authorization policy or an encryption guarantee. A signed token can remain cryptographically valid after membership changes; strict current-membership checks need current server state or a revocation mechanism. Role-based access control (RBAC) assigns permissions to roles. Attribute-based access control (ABAC) also evaluates properties such as tenant, owner, classification or environment. An invoice rule might require active membership AND invoice-read permission AND matching tenant AND any required owner restriction.

03Tenant-scoped authorization: worked invoice read

Consider the stored record Invoice(tenantId=Acme, invoiceId=I17, amountMinor=4500, ownerId=U9).

1. U9 requests GET /tenants/Acme/invoices/I17 with a valid credential.
2. The API authenticates principal U9 and verifies active Acme membership plus the invoice-read permission.
3. Data access executes a tenant-scoped lookup using both Acme and I17, then applies any finer owner or role rule.
4. The response includes only permitted invoice fields. A broad database row is not automatically an appropriate response representation.
5. An audit event records the principal, tenant, action, resource, decision, and trace ID without copying credentials or unnecessary invoice contents.

U10's identical URL fails authorization. Whether the external status is forbidden or not-found depends on the API's deliberate information-disclosure policy, but the record is never returned. Every object action—including update, attachment download, bulk export, and support tools—needs the same policy enforcement.

Define when revocation takes effect. An admission-time policy checks permission when accepting a request and allows that authorized request to finish even if access is later revoked. A release-time policy checks the required policy revisions as part of the protected decision to release the response, withholding it if they have changed. Neither can withdraw bytes the recipient already received.

04Shared tables, separate databases, and dedicated deployments

Tenant data can share progressively less infrastructure: rows within the same tables, separate databases, or separate application deployments. The choice changes how much routing and policy enforcement is shared, how failures spread, and how many resources must be operated separately. Every option still needs to map the authenticated caller to the correct tenant.

Database row-level security applies policies that restrict which rows a database role may read or change, providing another enforcement layer. In PostgreSQL, enabled row security without an applicable policy defaults to denial, but owners normally bypass it unless forced, and privileged roles can bypass it. Running the application with a broadly privileged role defeats the intended boundary. Understand the chosen database's exact behavior and keep application authorization as well.

A separate database does not fix a router that selects the wrong tenant database. Shared infrastructure can be safe with disciplined boundaries; dedicated infrastructure still needs correct identity, routing, backups, and operations.

05Tenant isolation in caches, search, jobs, and signed URLs

Suppose the cache key is only invoice:I17. Acme and Birch can both have an invoice I17, so one tenant can receive the other's cached value. Use a key such as tenant:Acme:invoice:I17:v3, and avoid sharing responses across different permission scopes when field visibility varies by user.

Search and vector retrieval must restrict candidate documents to those the caller may access before unauthorized content enters a response or an LLM prompt. Filtering only the final displayed citations is too late. A background export stores trusted tenant and principal context and checks whether its authorization remains valid when it runs or delivers results.

06Encryption in transit, encryption at rest, and data lifecycle

TLS encrypts data in transit and authenticates the intended peer under its trust model. Encryption at rest protects stored bytes against some storage-access threats. Neither protects against an application that legitimately decrypts and then sends a record to the wrong caller.

Use managed key storage or an equivalent protected mechanism, tightly scope decryption permissions, and rotate credentials without putting secrets in source code or browser bundles. Tenant-specific keys can improve separation and lifecycle control but add management and availability dependencies. If the service must search plaintext, explain where decryption occurs and who can access it.

Backups, analytics extracts, dead-letter queues, logs, and support exports also contain data. Apply retention, access control, and deletion workflows to those paths. A deletion request may require immediate loss of application access followed by documented physical cleanup and backup-expiry behavior, rather than an impossible claim that every historical byte vanishes instantly.

For large files, the key service should control access to decryption keys without processing every file byte. Envelope encryption separates those jobs: the application encrypts the bulk data, while a protected service controls the key needed to decrypt it. The following two-key arrangement makes that separation possible.

Envelope encryption separates the key encrypting data from the key protecting that key. Generate a data-encryption key, encrypt the object with an authenticated-encryption scheme, then wrap the data key under a protected key-encryption key, commonly managed by a key management service (KMS). Store the ciphertext (encrypted bytes), wrapped data key, and algorithm/version metadata. Also store the algorithm’s required nonce or initialization vector (IV), an input used for that encryption operation, and its authentication tag, which lets decryption detect tampering. Use a vetted encryption library and follow the selected algorithm’s nonce-uniqueness rules. An authorized reader unwraps the key and decrypts; plaintext keys must not appear in logs or persistent metadata.

This keeps bulk data encryption outside the key service and permits rewrapping keys without necessarily rewriting all ciphertext. That benefit comes with key-service latency, quotas, permissions and recovery dependencies. Rotating a wrapping key is not the same as changing every data key or erasing old data. Application authorization remains necessary after decryption.

07Noisy-neighbor controls and cross-tenant security tests

A noisy neighbor is a tenant whose workload consumes shared resources and degrades others. If Acme launches 10,000 exports, Birch's invoice reads should not wait behind an unbounded queue. Apply per-tenant quotas, bounded concurrency, fair scheduling, and separate pools for expensive background work.

At an assumed two CPU-seconds per export, 10,000 exports need 20,000 CPU-seconds before I/O overhead. A pool limited to 20 fully utilized cores needs roughly 1,000 seconds, or 16.7 minutes, just for that work. Queueing and asynchronous delivery are reasonable; pretending every export can finish immediately is not.

Audit access and quota decisions, alert on unusual cross-tenant denial patterns, and test with two real tenant fixtures. Include negative tests: a valid Birch credential requesting Acme resources, an old signed link after the allowed expiry, and a job whose initiator lost membership. The result should prove the boundary at each route, not merely prove successful login.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.