Scope Cross-Tenant Integrations

An external integration may be installed by one user and then used by an entire organization. Its token may remain after that user leaves. If connections are stored by provider account alone, another tenant can select the wrong one. Treat the connection as a tenant-owned resource with its own lifecycle. OWASP Multi Tenant Security applies to shared integration records.

Connection ownership table

A provider token is not a tenant permission. The app must check the current caller's organization and action before it uses the connection. A local delete may not revoke a copied provider token. Verify provider-side revocation when supported; mark it unknown when not verified.

Test transitions

Use synthetic Tenant A and B connections to a provider sandbox or a local mock. Ask A to use its connection, then request B's connection ID. Confirm denial before any external call. Remove the installer, change a user's role, rotate the provider token, and disconnect. Check whether queued jobs still run under the written policy. Inspect logs for token values and tenant mismatches.

The OWASP OAuth2 Cheat Sheet gives token-handling context. This ownership table joins provider consent to application authority. It is useful for marketplace and SaaS integrations, but it does not prove every provider's revocation behavior. Keep real credentials out of public examples and initial review inquiries. A scoped review of a customer integration needs separate written permission.

Illustrative mapping fixture: connection C1 binds provider account P1 to tenant A. After disconnect, a callback for P1 must not create an A or B job. Reinstall P1 for A as connection C2, then require callbacks to resolve only through active C2; a stale C1 lookup fails. A B caller cannot select C2 for outbound use. Record the provider account identifier, connection version, active state, and final tenant decision without storing provider tokens.