Multi-Tenant Authentication Without the Footguns
By The Alt Auth Team
Multi-tenancy is where most home-grown auth starts to hurt. The first version assumes one user belongs to one company. Then a consultant joins two customers, an agency manages five, someone gets promoted in one organization and stays a viewer in another — and the schema that seemed obvious is suddenly wrong everywhere.
Roles belong on the membership, not the user
The single most expensive shortcut is putting a role column on the user record. It works until the first person needs different permissions in two places, and by then the assumption has leaked into every query and every UI check. Roles belong on the relationship between a user and an organization, from the very first migration.
Decide what a token means
- A token scoped to one organization is simpler to authorize and safer to leak — but forces a re-issue on switch.
- A token listing every membership avoids the round trip and complicates every permission check.
- Whichever you choose, write it down. The failure mode is two services assuming different answers.
- Never let the client pick the active organization without the server confirming membership.
“Almost every multi-tenant breach story is the same sentence: the tenant identifier came from the request and nobody checked it.”
Alt Auth models organizations, memberships, ownership levels and manager roles directly, so the structure exists before you need it — and Business adds multiple organizations under one account for customers who run several.