Last updated: September 2026
Auth0 has been packaging B2B tenancy in stages through 2026: Tenancy-as-a-Service was announced in March 2026 and is now generally available, Enterprise Connect went to beta in July 2026, and B2B Connect is in beta with early access due in late September 2026. The common pitch is that you add enterprise SSO, federation and multi-tenant identity to an existing stack without migrating users, applications or tokens. Keycloak answered the same buyer problem from the other direction in 26.7, released 9 July 2026: organizations became a first-class resource type in Fine-Grained Admin Permissions, with three new realm roles, so a customer administrator can manage their own organization without manage-realm.
Both vendors spent 2026 on the same bottleneck, which is delegated administration. The comparison worth making is not the feature lists, which overlap heavily, but what each approach assumes about who owns the identity layer afterward.
What has Auth0 shipped for B2B SaaS in 2026?
Three related releases at three different stages, and the naming has shifted along the way.
Tenancy-as-a-Service was announced in March 2026 during Auth0’s spring launch week and is generally available. It covers the operational side of onboarding corporate customers: creating tenants, letting those customers administer themselves, and keeping customer environments separated.
Enterprise Connect entered beta on 30 July 2026, described by Auth0 as a way to use Auth0 as a modular B2B identity layer.
B2B Connect is in beta, with early access due in late September 2026 per Okta’s September 2026 launch announcement. It is aimed at companies that want enterprise single sign-on, federation and multi-tenant identity tools without replacing the identity infrastructure they already run, with a stated target of delivering that in 90 days or less.
Enterprise Connect and B2B Connect describe closely overlapping capabilities under different names, and Auth0 has not published a clear statement of how the two relate. Treat “B2B Connect is brand new in September” as marketing framing rather than product history: the capability has been in beta under at least one name since July.
Our read: the recurring word across all three announcements is “without”. Without migration, without rip-and-replace, without touching your tokens. That is a product line designed to be adopted by teams who are not handing over the whole identity layer, which describes a real and large segment of the market. It also means what you are evaluating is a coexistence layer rather than a platform move, and coexistence layers deserve an explicit exit plan at the point you adopt them, not later.
Does Keycloak Organizations solve the same problem?
Keycloak Organizations models the tenant directly: an organization holds members, brokers its own identity providers, and can carry its own branded login. That covers the tenancy half of what Auth0 packaged, and it has been in Keycloak for several releases. Our multitenancy in Keycloak using the Organizations feature walkthrough covers the model itself.
What Keycloak was missing until recently was delegation, and 26.7 closed that gap.
Before 26.7, letting a customer administer their own organization meant granting manage-realm, a role the release notes describe as “a high-privilege role that grants far more access than most organization administrators need.” Handing a customer’s admin manage-realm gives them the whole realm, so the common workaround was a custom admin portal built against the Admin API, which is weeks of work and a new attack surface. The team management surface is what that portal was standing in for.
Keycloak 26.7 introduced three realm roles for coarse-grained delegation:
manage-organizations, full read and write on organizations and their members, including create, update and deleteview-organizations, read-only on organizations and members, which also needsview-usersor Fine-Grained Admin Permissions for member visibilityquery-organizations, search and list without full view access, matching the existingquery-usersandquery-clientspattern
manage-realm still implicitly grants full organization management, so nothing breaks on upgrade.
How does per-organization scoping work?
Organizations became a first-class resource type in Fine-Grained Admin Permissions, so a permission can name specific organizations rather than all of them. The release notes give the shape directly: an administrator can be granted the ability to manage one organization without gaining access to every organization in the realm.
One detail is easy to miss and matters for anyone building a multi-tenant admin experience. When FGAP is enabled, organization member queries also respect user-level permissions, returning only the members that administrator is permitted to see. Without that, a scoped admin could enumerate users outside their tenant through the member listing, which is the kind of leak that makes a tenancy model unusable for regulated customers.
If FGAP is new to you, our fine-grained authorization in Keycloak explained post covers the underlying model, and the Organizations CVE patch checklist is worth reading alongside it, because this surface has had security fixes and delegated admin is where they matter most.
What changed for roles inside an organization?
Organization groups now carry realm and client role assignments, which removes the per-member role assignment that does not scale. Assign a role once to the organization group and it appears in realm_access and resource_access claims for every member of that group.
The Organization Group Membership protocol mapper, for both OIDC and SAML, can nest those roles inside the organization claim, organized per organization, when “Add group role mappings” is enabled:
{
"organization": {
"acme": { "roles": ["tenant-admin", "billing"] },
"globex": { "roles": ["viewer"] }
}
}Without per-organization nesting, an application receiving tenant-admin in a flat realm_access list has no way to tell which tenant it applies to, and every multi-tenant authorization decision becomes a second lookup against your own database. This arrived in the same release as the delegation roles, and the two together are what make Organizations usable as a tenancy model rather than a grouping construct.
Which approach should you pick?
There are three routes, and the deciding factor is usually where your identity layer is heading rather than any individual feature.
Stay on Auth0 and add B2B Connect. This fits when an enterprise deal is closing this quarter, your consumer login works, and the team has no appetite for a migration. You are buying time and a supported path. The trade is that the coexistence layer becomes part of your architecture, and removing it later means unpicking whatever your applications came to depend on.
Move the B2B surface to Keycloak Organizations. This fits when you already run Keycloak, or when enterprise tenants are the business rather than a segment of it. As of 26.7 the delegated-admin gap that made this painful is closed, which was the main technical objection a year ago. The trade is that Organizations and FGAP become configuration surfaces you own.
Split them. Keep consumer identity on Auth0 and put enterprise tenants on managed Keycloak. This is defensible when the two populations genuinely have different requirements, and it is worth choosing deliberately rather than arriving at it through an unfinished migration, because the cost is two identity systems and two on-call rotations.
For teams leaning toward the second route, migrating from Auth0 to Keycloak step by step covers the mechanics, and the general Keycloak vs Auth0 comparison covers the platform ground this post does not.
How do the pricing models differ?
They price different things. Auth0 prices identity as a service on monthly active users, with B2B capabilities gated behind B2B plans: as of July 2026 its published list prices start at $150 per month for B2B Essentials at 500 MAUs, which is the tier that adds Organizations and enterprise SSO connections, and $800 per month for B2B Professional at the same user count. Enterprise connections beyond a plan’s allotment are sold separately, so past that allotment adding a federated tenant is a commercial decision as well as a technical one.
Skycloak prices the infrastructure that runs an open-source server, so adding an organization with a brokered identity provider is a configuration change. That is our model specifically rather than a property of managed Keycloak in general: other providers in this space price per user or per project, and the differences are laid out in managed Keycloak providers compared.
Rather than repeat the arithmetic here, the full dated comparison at 1,000, 10,000 and 100,000 MAUs is in our Keycloak vs Auth0 comparison guide, including where the crossover falls. Check both vendors’ current pricing pages against your own user counts before deciding, because tiering changes often enough that any figure in a blog post carries a date stamp for a reason.
On portability, Keycloak Organizations is upstream open source, so a realm export moves to any Keycloak, managed or self-hosted. A coexistence layer configured inside a proprietary product exports as configuration that only means something inside that product, which is a different kind of dependency and worth pricing at adoption time. Our B2B SaaS evaluation of Keycloak goes into where that matters commercially, and SCIM 2.0 with managed Keycloak covers the provisioning piece enterprise tenants ask for next.
What we see: the delegated-admin question is usually what decides this, and it rarely appears in the evaluation criteria at the start. Teams compare SSO protocol support, find both options support SAML and OIDC, and conclude the products are equivalent. Then the first enterprise customer asks to manage their own users, and the real requirement surfaces six weeks into the implementation. That question belongs at the top of the evaluation.
Where managed Keycloak fits
Skycloak is identity management as a service built on upstream Keycloak, so the Organizations and FGAP behaviour described here is the upstream behaviour rather than a fork. What changes is who runs the cluster, tracks the security fixes on the organizations surface, and carries the upgrade testing when a minor release changes the admin permission model.
For a B2B SaaS team, the comparison is between an identity product that packages tenancy and a managed open-source server that implements it, and both are reasonable answers depending on the three routes above.
FAQ
What is Auth0 B2B Connect?
An Auth0 offering for adding enterprise SSO, federation and multi-tenant identity to an existing identity stack without migrating users, applications or tokens. Per Okta’s September 2026 announcement it is in beta with early access due in late September 2026. A closely related beta, Enterprise Connect, opened on 30 July 2026.
When did Auth0 Tenancy-as-a-Service launch?
It was announced in March 2026 during Auth0’s spring launch week and is now generally available. Okta’s September 2026 release restates its GA status rather than introducing it, which is a common point of confusion in coverage of that announcement.
Can Keycloak do multi-tenant B2B authentication?
Yes, through Organizations, which model tenants with their own members, brokered identity providers and branded login. Keycloak 26.7 added organization-scoped Fine-Grained Admin Permissions and three delegation roles, closing the gap that previously forced teams to grant manage-realm or build a custom admin portal.
How do I let a customer admin manage only their own organization in Keycloak?
Use Fine-Grained Admin Permissions with organizations as the resource type, which scopes a permission to named organizations rather than all of them. Combine it with manage-organizations or view-organizations rather than manage-realm. With FGAP enabled, member queries also respect user-level permissions.
Do organization roles appear in the token?
Yes. Since 26.7, organization groups carry realm and client role assignments that surface in realm_access and resource_access. The Organization Group Membership mapper, for OIDC and SAML, can nest those roles inside the organization claim per organization when “Add group role mappings” is enabled.
Sources
- Okta, “Okta launches new identity innovations to unlock business growth in the agentic era,” September 2026, retrieved 2026-09-13, https://www.okta.com/newsroom/press-releases/auth0-launches-new-identity-innovations/
- Auth0, “Why Your Growth Strategy Needs Auth0 Tenancy-as-a-Service,” March 2026, retrieved 2026-09-13, https://auth0.com/blog/introducing-auth0-tenancy-as-a-service/
- Auth0, pricing page, list prices as of July 2026, https://auth0.com/pricing
- Keycloak, release 26.7.0 notes, “Fine-grained delegation for organization administration,” retrieved 2026-09-13, https://github.com/keycloak/keycloak/blob/main/docs/documentation/release_notes/topics/26_7_0.adoc
- Keycloak, release 26.7.0 notes, “Automatic role inheritance through organization groups,” retrieved 2026-09-13, https://github.com/keycloak/keycloak/blob/main/docs/documentation/release_notes/topics/26_7_0.adoc
- Keycloak, issue 45497, organization admin permissions, https://github.com/keycloak/keycloak/issues/45497
- Keycloak, issue 47327, organization group role mappings, https://github.com/keycloak/keycloak/issues/47327