The Hidden Risk of Cross-Tenant Identity Confusion

Invitation workflows are a core part of modern SaaS applications: a tenant administrator invites a user, the user receives an email, accepts the invitation, and joins the workspace.

At a business level, this flow is simple and necessary. However, at a security level, invitation workflows represent one of the most sensitive identity operations in the application.

It is often the first moment where an application decides:

• how a new tenant membership is created,

• which identity becomes associated with that membership,

• what tenant-scoped permissions are assigned,

• which tenant context the identity belongs to,

• and what attributes will later be trusted during authorization.

In the Attack Surface Series

Part 2 of our “When Identity Becomes the Attack Surface” series explores how invitation workflows can create an identity foothold, and how that foothold can expose deeper tenant isolation flaws caused by inconsistent identity resolution.

When an Invitation Becomes More Than an Invitation

An invitation flow should look simple:

At first glance, this appears safe: the user receives an invitation, clicks the link, and joins the tenant.

In a secure model, the inviter can start the process, but only the invited mailbox owner should be able to complete setup, create credentials, and activate access.

Observed Pattern

During offensive security testing, a recurring pattern was identified where an administrator inviting a user receives the invitation link in the application response. This is often implemented for convenience, debugging, internal workflows, or frontend rendering.

That design can be risky. Developers may assume that an administrator would never attempt to use the link themselves. They may also overlook that invitation links often act as a form of email verification, because the application assumes the invitee received the link through their inbox.

If that assumption is wrong, what was intended as a simple onboarding feature can become a foothold that exposes deeper authorization flaws in the application.

What This Looks Like in Practice

Invitation Creation

A typical administrative invitation request may look like:

The application responds:

As shown above, the response contains one important signal that should be reviewed carefully: a usable invitation or setup URL was returned to the inviter. Why Returning Invitation Links Can Be Dangerous

Invitation links often act as more than simple navigation links. In many applications, they are treated as proof that whoever opens the link controls the invited email address, because the application assumes the link was delivered only to that person’s inbox.

That assumption breaks when the same invitation link is returned to the administrator who created it. At that point, the link is no longer controlled exclusively by the invitee. If the inviter can open that link and complete onboarding steps such as accepting the invitation, creating a session, or setting a password, they may be able to create a valid identity using the victim’s email address without ever proving control of the victim’s mailbox.

In applications that use tenant-local identities, this may initially appear safe. The same email address can exist as separate user records in different tenants, each with its own scoped identity: a unique userId and membershipId bound to that tenant. In a correctly isolated system, authorization should always resolve against that full tuple, never against the email address alone.

When Tenant Isolation Fails

During offensive security testing, tenant isolation in these models was found to fail when identity resolution became inconsistent.

The application may rely on tenant-scoped user IDs in some places, but treat email as the authority for resolving users, memberships, resources, or data in others. This can happen when certain backend paths, whether introduced by implementation mistakes or inherited from legacy identity models, still trust the shared email address over the tenant-scoped identifier.

In other words, the system separates identities like this:

Tenant A: victim@example.com -> user_A

Tenant B: victim@example.com -> user_B

But some backend functions may still behave as if this were true:

victim@example.com -> same user everywhere

When identity resolution is inconsistent, even standard backend functions become dangerous. The following are examples of operations that if they resolve by email alone can silently cross tenant boundaries:

getMemberships(email)getProjects(email)getNotifications(email)getResources(email)getPermissions(email)getAuditEvents(email)getApiKeys(email)getBillingContext(email)getInvoices(email)getIntegrations(email)

Any function that accepts an email address as its primary lookup key, without also scoping to a tenant identifier, is a potential cross-tenant data leak.

That inconsistency defeats the purpose of having separate user IDs per tenant.

The Point Where Both Conditions Intersect

When both conditions exist together, the invitation flow creates the foothold, and inconsistent identity resolution turns that foothold into cross-tenant access. At that point, the attacker neither needs the victim’s password nor their mailbox.

They only need a valid identity using the same email address, and one backend path that resolves sensitive users, memberships, permissions, or resources by email instead of by tenant-scoped identifiers.

Visualizing the Complete Attack Chain

Secure Design Principles

To prevent invitation workflows from becoming a foothold for cross-tenant data exposure, identity boundaries must remain consistent throughout both onboarding and authorization.

1. Invitation Links Should Remain Private

Invitation or setup links should be delivered only to the invited email address. They should not be exposed through API responses, frontend state, logs, debugging interfaces, or administrative dashboards unless there is a strong and well-controlled business requirement.

The actor creating the invitation should not automatically gain the ability to complete setup on behalf of the invited identity.

2. Tenant Membership Should Be Activated Only by the Invited Identity

Creating an invitation should not allow the inviting tenant administrator to create or authenticate a new identity using the invited email address.

The invited identity should first authenticate and explicitly accept the invitation before tenant membership becomes active.

3. Authorization Must Always Use Tenant-Scoped Identifiers

Once authenticated, backend authorization should consistently resolve users, memberships, permissions, resources, and organizational context using tenant-scoped identifiers such as:

userId + tenantId + membershipId (or an equivalent tenant-scoped composite identifier)

Shared attributes such as email addresses should never be treated as the primary authority for sensitive authorization decisions.

4. Shared Attributes Should Never Cross Tenant Boundaries

Attributes such as email addresses, usernames, display names, or external identifiers may be reused across tenants, but they should never be used by themselves to resolve memberships, permissions, resources, or organizational context across tenant boundaries.

5. Legacy Identity Resolution Paths Must Be Eliminated

Applications evolving from single-tenant or global identity models should audit older services, helper functions, and internal resolvers to ensure they do not continue resolving identities using shared attributes such as email addresses.

Even a small number of legacy code paths can silently bypass tenant isolation in otherwise secure systems.

Conclusion

Invitation workflows are often viewed as onboarding features.

In reality, they are identity-boundary decisions.

The critical question is not:

Can an administrator invite a user?

The better question is:

What happens when the same administrator receives the invitation link and creates a tenant-local identity using it exactly as the system allows? And what happens later, when backend paths trust that identity's shared attributes beyond the intended tenant boundary?

Because in modern SaaS applications, cross-tenant security failures rarely begin with broken authentication.

They often begin when a trusted invitation link is returned to the wrong context, a valid identity is created exactly as designed, and later backend paths silently resolve that identity as if it belonged everywhere.

That is what makes this class of issue difficult to detect, and dangerous.