A shared service account is not per-tenant authorization

A single service account providing access to multiple systems and APIs is not an adequate form of authorization for individual tenants. This type of credential, often referred to as a "god-mode" secret, grants permission to perform any action across the entire system. However, it does not restrict the actions to only those that should be taken for a specific tenant.

When a request is made for tenant A and triggers a write, send, or export, the privileged service account may inadvertently modify data belonging to tenant B, as it lacks the necessary tenant-specific permissions.

To implement proper authorization, the service account should be viewed as an upper limit on the process's capabilities, not a guarantee that a specific effect is permitted. It is crucial to verify authorization (or at least enforce the same tenant/resource scope as used in online APIs) for every side effect, regardless of whether the code path is executed synchronously or asynchronously.

Background jobs, cache layers, search indexes, and bulk operations all require explicit tenant identification before performing any action that could potentially modify data.

Prefer using short-lived, narrowly scoped tokens for each tenant or each effect when making outbound calls, rather than relying on a single, powerful service account for all processes. This approach limits the potential damage in case of a security breach or misconfiguration. Additionally, log relevant information such as the tenant ID, resource ID, and the service identity used for each action.

Failing to include the tenant ID in logs makes it difficult to track the source of any incidents or anomalies, rendering them practically useless in post-incident analysis.

To illustrate the importance of tenant-specific authorization, attempt to execute the same code path using the shared service account while targeting a resource ID from a different tenant. If the action succeeds solely due to the powerful credentials, it indicates that no tenant-specific authorization was enforced. The shared service account should only be used as a means to authenticate the process, not as a substitute for proper authorization. Authorization decisions must still be made for each object, regardless of how it is accessed.