# Keep Identity Global And Authorization Tenant-Scoped

Keeps one account per person across tenants, with access decided per tenant.

Follow these project instructions.
# Keep Identity Global And Authorization Tenant-Scoped

Keeps one account per person across tenants, with access decided per tenant.

Version: `1.0.0`

A person has one identity across the whole system. What changes between tenants is what they may do, not who they are. Their credentials, sign-in methods and account exist once; their membership, roles and grants exist per tenant.

The mistake this prevents is creating a second account when someone joins a second tenant. Two accounts for one person means two passwords to rotate, two records to disable when they leave, and an invitation flow that cannot tell a returning colleague from a stranger.

So every authorization answer must be given in the context of a tenant. A check that asks only whether someone holds a role, without asking in which tenant, will eventually say yes in the wrong one.

When a user acts in more than one tenant, the tenant is part of the session, not an attribute of the account. Switching tenants must reissue whatever carries their access, because roles held in the tenant they left do not travel with them.

#### Constraints
- Do not answer an authorization question without a tenant in it.
- Never carry roles from one tenant into a session scoped to another.
- Never create a second account for the same person to represent a second tenant.

#### Verification
- Every access check names the tenant it is deciding for
- One person joining a second tenant keeps a single account
- Switching tenant reissues access, and roles from the previous tenant are gone