How do I map SSO users to the right tenant and role in our app?

A good way to do this is to treat your SSO login as authentication only, then do authorization mapping in your app based on stable identity claims and your own tenant/role rules.

Recommended approach

1) Use a stable SSO identifier

From the IdP, store a unique immutable user key such as:

• sub for OIDC
• oid / tid combinations for Azure AD
• NameID for SAML, if it is guaranteed stable
• email only as a fallback, not the primary key

Create a user table like:

• id
• sso_provider
• sso_subject
• email
• name
• status

Then link that user to your app’s tenant and role tables.

---

2) Map tenant membership in your app

Do not infer tenant purely from the email domain unless your business rules are very simple.

Instead, maintain a mapping such as:

• user belongs to one or more tenants
• each membership has a role

Example schema:

• tenants(id, name, ...)
• users(id, sso_subject, email, ...)
• tenant_memberships(user_id, tenant_id, role, is_default)

At login:

1. Find the user by SSO subject
2. Load all tenant memberships
3. If only one tenant, assign it automatically
4. If multiple tenants, choose via:
   • explicit tenant in URL
   • user selection screen
   • default tenant
   • IdP claim if your enterprise setup supports it

---

3) Map role from app policy, not directly from SSO unless trusted

You have two main patterns:

Pattern A: App-managed roles

Best for most apps.

• SSO confirms identity
• Your app stores roles:
  • admin
  • member
  • viewer

This gives you control and avoids surprises when IdP groups change.

Pattern B: IdP group/claim-driven roles

Use if you want central IT to manage access.

Example:

• SSO group sales-admins → app role admin
• SSO group sales-users → app role member

Then maintain a mapping table:

• idp_group
• tenant_id
• app_role

Be careful: group-based authorization can become messy across tenants unless you namespace groups by tenant.

---

4) Support multiple tenants and roles cleanly

A user may have:

• one SSO identity
• multiple tenant memberships
• different roles in different tenants

Example:

• Alice is admin in Tenant A
• Alice is viewer in Tenant B

Your app should resolve role based on the currently selected tenant, not globally.

---

5) Handle first login provisioning

When a new SSO user logs in:

• create the user record
• look up whether they should be auto-assigned to a tenant
• optionally enforce invitation-only access
• assign a default role if your business rules allow it

Common strategies:

• Just-in-time provisioning: auto-create user on first login
• Invite-only: only users with a pre-created invitation can log in
• Domain-based auto-join: users from @company.com join Tenant X automatically

---

Suggested login flow

1. User authenticates with SSO
2. App receives verified identity claims
3. App looks up internal user by (provider, subject)
4. App loads tenant memberships and roles
5. If multiple tenants:
   • use requested tenant context if valid
   • else prompt user to select tenant
6. Issue app session with:
   • user_id
   • tenant_id
   • role
7. Enforce authorization on every request using current tenant context

---

Security tips

• Never trust client-side tenant or role values
• Never grant access only because the email domain matches
• Prefer immutable IdP IDs over email
• Re-check authorization when switching tenants
• Log mapping decisions for audits
• If using group claims, verify token signatures and freshness

---

Simple rule of thumb

• SSO identity = who the user is
• Tenant mapping = which customer/account they belong to
• Role mapping = what they can do in that tenant

If you want, I can also show:

1. a database schema for this,
2. a JWT/claims mapping example, or
3. an implementation example for OIDC, SAML, Auth0, Azure AD, or Okta.