Organizations

A personal organization can later become a customer one, in place and only in that direction; an internal organization never changes kind and a customer organization never goes back.

An organization can have a parent. The hierarchy is at most three levels deep. A child may only tighten what its parent sets: its effective value of each rule below is its own value narrowed by every ancestor's. A forbid policy written in a parent also applies in its children. See Authorization.

An organization is active, suspended, deleting or deleted. When an organization is suspended, its sessions are refused on the next request and a token that names it is treated as inactive. Token exchange also refuses a subject whose organization is not active.

An organization can set rules that apply when its members sign in to it. Each has a platform default, and an organization can only choose values inside the range the platform allows.

Two more rules exist for single sign-on. sso.enforce requires members to hold a linked identity from one of the organization's sign-in connections (or an ancestor's), and sso.max_age_s is how old that sign-in may be (default 86400 seconds). guests_exempt exempts guests from it. guests.allowed controls whether the organization may hold guest memberships. Enforcement applies only while the sso_enforcement flag is on, and it defaults OFF. A person who lacks a recent enough single sign-on sign-in gets an insufficient_user_authentication answer at the token endpoint.

A minimum level above 1, or an allowed-method list that leaves out the plain password, is a hard rule: the platform's "a correct password always signs in" does not override it. A member who holds a passkey or an authenticator app is asked for it, and "Continue with my password only" is not offered; a member who holds none is refused with the reason Your account has no passkey or authenticator app, and your organization needs one. and pointed to account recovery, which has no hold on an account with nothing set up. (See Sign-in errors and what they mean.)

These rules are read at sign-in for sign-ins that are scoped to the organization. A person with no organization selected gets the platform defaults. The concrete numbers are on Session lifetimes.

An organization can tighten the lifetime of a session. When an application asks to sign someone in to an organization whose limits are stricter than the platform default, a session older or idler than the organization allows is asked to sign in again, even though the session itself is still open.

• If your account belongs to more than one organization, sign-in stops at Choose an organization. It says that your account belongs to more than one and asks you to pick the one to continue with. When you belong to many, a Filter organizations field helps you find it.
• An application can preselect an organization. It sends the organization's canonical id in the tdaid_tenant parameter, not its slug, because a slug can change.
• If the application preselects an organization where you have no active membership, the request is refused with access_denied. The same refusal applies when the application's product is not installed in that organization, so the two cases cannot be told apart.
• If the application does not require an organization and your signed-in organization is one it cannot enter, you are signed in without an organization instead of being refused. An application that requires one, or a request that names one, is refused.
• When your email domain routes to exactly one active sign-in connection of an organization, sign-in can send you there: Sign in with your organization says the organization manages sign-in for your email address, with Continue with the organization and Use another method (flag tenant_connections, which defaults OFF).
• Sign-in can also stop at Create your workspace when an application needs an organization and you have none. It says you do not have one yet and starts you as its only member.

When a sign-in belongs to an organization, the tokens carry the organization's id as tid and its slug as tslug.

• Use tid for decisions. It never changes.
• Use tslug only to display. It is readable but can be renamed.

The consent screen describes the scope as Your organization: it tells the app which organization you are signed in to. See Scopes and consent.

The account session may carry an organization. The usual account sign-in has none; an application sign-in carries the one it picked, and the account area follows the session. The organization switcher at the top of the account navigation (a plain label with one active membership, a menu with more) always names one organization: the session's, else the one last used on this browser, else the personal workspace, else the first active one. The last-used organization is remembered per browser in the HttpOnly hint cookie __Host-tdaid_org, and when the session has none the page tries once per tab to enter it, only when no extra step is needed. The switcher changes the organization. A switch does not edit the session. It signs the same person in again, in the chosen organization, from the session they already hold, and runs the same checks as an organization sign-in: an active membership, the single sign-on rules, the organization's minimum assurance level and allowed methods, and a second factor when needed. The new session keeps the time the person last authenticated from the session it came from, and an organization the person may not enter gets one answer, whatever the reason. Applications keep their own tokens and sessions. See Changing organization.

Which actions you may perform inside an organization is not stored in your token. The authorization service decides it from the role assignments you hold there. See Authorization and Permissions and roles.

• Memberships and invitations
• Organizations in your account