Organizations, environments and tenant isolation

Projects and environments#

A project has one development and one production environment. Each environment is a separate world: its own client ID, API keys, signing keys, users, organizations, branding, redirect URIs, webhooks and settings. Build against development and ship with production's credentials.

Organizations#

Organizations group the users of an environment, for example your customers' companies. An organization has members with roles, can verify email domains, and can have SAML connections and domain policies. A user can belong to several organizations; the session carries one current organization_id, and its roles and permissions are that organization's.

Switching organization#

OrganizationSwitcher lists the user's organizations from your /api/auth/organizations and switches through POST /api/auth/switch-organization. That refreshes the session for the chosen organization, so roles and permissions follow, and refuses an organization the user doesn't belong to (403 not_a_member). It is hidden when the user belongs to fewer than two.

Tenant isolation#

• User lookups are scoped to the project and environment. The same email in two environments is two unrelated users.
• Tokens are signed with a key per environment and verified against that environment's key set only. A token from another environment, another customer or the 3een dashboard does not verify in your app.
• An API key acts only within its own environment.
• Sign-in codes are bound to the environment and the exact redirect URI they were issued for.