Separate tenants. Separate signing keys.

A tenant has a globally unique slug, and its issuer lives at a hostname derived from it. That URL is the OIDC issuer value and the base for everything the tenant serves: discovery, the key set, authorize, token, userinfo, SAML metadata, SAML sign-on and SCIM. The tenant is resolved from the host a request arrived on.

The slug is immutable after creation, because it is baked into the issuer URL every relying party trusts; renaming it would break each of them. A tenant's human-readable display name can be changed freely. Common infrastructure labels are reserved and refused.

The practical consequence for a relying party is that the unit of integration is a tenant, never the platform as a whole. Resolve endpoints from that tenant's own discovery document, read the issuer claim to learn which tenant minted a token, and verify the signature against the key set published at that issuer.

Every user, application, group, role, resource server, scope and signing key belongs to exactly one tenant. The constraint is attached to the query itself: each read is narrowed to the account and tenant that authenticated the request, before any result exists to be filtered. Removing an option from a menu is a change to a screen, and we do not describe that as isolation.

Ask for an object belonging to another tenant and the answer is a not-found, not a refusal. Treating those two responses as interchangeable is the mistake that lets an attacker walk an identifier space and come away with a list of your customers, which is why the boundary refuses to confirm that anything is there at all.

Cryptography stands behind the query scoping. A client registered in one tenant is refused on another tenant's issuer host, and a token minted in one tenant cannot verify against another's key set at all, so an application bug cannot quietly become a path between two customers.

If you serve many customers from one deployment, the tenant becomes the unit of onboarding. Taking on a new customer means creating a tenant rather than standing up infrastructure, and every account starts with one default tenant that cannot be deleted.

If your code touches more than one tenant, treat each as a fully separate identity provider: its own issuer, its own key set, its own client registrations. Nothing from one is usable in another, so cache per issuer and avoid hard-coding a hostname or a path beyond the issuer base.

Customers can also federate on their own terms. One customer can push users from their own directory over SCIM while the next manages people by hand in the console, and one can connect over SAML while another uses OIDC. The boundary is what makes that a per-customer choice instead of a platform-wide decision.

Inside every tenant the sign-in is the same live face ceremony, and at no point does it involve a password or a one-time code. In business software that removes the habit small teams drift into, where a single login circulates quietly around a department because nothing stops it.

A tenant can serve that sign-in under its own verified custom domain, so the people signing in see a hostname that belongs to the product they are using rather than to a vendor they have never heard of.

Because there is no identity provider side SSO session for end-user authentication, somebody who works across two of your customers authenticates in each one, and enrollment is per tenant as well. That is the cost of a boundary that holds, and it is a cost worth naming before a design is committed.