With Keycloak 26, the project has taken a significant step toward structured tenant models: Organizations are now a supported, production-ready feature and are specifically designed to address business-to-business and CIAM scenarios within a realm. At the same time, traditional tenant separation via separate realms remains an established and proven architectural principle.
For companies, this raises an increasingly important question: When does it make sense to separate clients at the realm level—and when is an organization-based model within a realm more appropriate?
This article compares both approaches in Keycloak 26 and highlights typical use cases, advantages, limitations, and decision-making criteria from a business perspective.
Client Isolation in Keycloak – A Brief Overview
Keycloak does not support “switch-based” multi-tenancy; instead, it offers various structural levels to logically or technically separate identities. In practice, the following two strategies are used in particular:
- Client isolation via realms → strong technical isolation
- Client isolation via organizations within a realm → logical isolation with a shared base configuration
Both approaches address different problems—and are not intended to replace one another, but rather to complement each other.
Option 1: Client isolation via separate realms
Concept
In Keycloak, a realm is a completely isolated identity domain. Each realm has its own configuration, including:
- Users, Credentials, and Federation Sources
- Clients and Client-Bereiche
- Roles, Groups, and Permissions
- Authentication flows
- Token signature keys and session policies
- Administrator permissions
There is no shared data or processes between realms.
Typical business use cases
Realm-based client separation is particularly suitable for:
1. Strictly Separated Identity Domains
- Internal employees vs. external customers
- Partners with their own security policies
- Different compliance frameworks (e.g., KRITIS vs. CIAM)
2. Different applications or platforms
- Separate app ecosystems
- Various token formats or claim models
3. Regulatory or organizational isolation
- Segmentation by business unit
- Separate operational or liability contexts
Advantages
- Very high insulation
- Maximum flexibility per client
- Clear separation of administrative responsibilities
- Easy to track during security audits
Limitations
- High operational and maintenance costs for multiple realms
- Configuration Duplication (Clients, Flows, Roles)
- Updates, changes, and rollouts do not have a centralized impact
- Does not scale well organizationally with many clients
Option 2: Client separation using organizations within a realm
Concept
Organizations represent a logical tenant structure within a realm. They have been specifically designed for B2B and CIAM scenarios and enable multi-tenancy without complete isolation.
Among other things, organizations allow:
- Assigning users to organizations
- Organization-specific identity providers
- Inviting and Onboarding Organization Members
- Organization-aware sign-in (e.g. based on email domain)
- Organization-specific claims in the token
However, custom clients, roles, themes, or completely isolated admin concepts per organization are not permitted.
Typical business use cases
Organizations are particularly well-suited for:
1. B2B SaaS platforms
- Several client organizations
- Everyone accesses the same application
- Different SSO integrations per customer
2. Partner and Customer Accounts
- Externally managed identities
- Automatic routing to the appropriate IdP login
3. Centrally managed platforms
- A security model
- A set of roles and clients
- Clear separation at the technical level
Advantages
- Central Administration of a Realm
- Excellent scalability for multiple clients
- Reduced operating and maintenance costs
- Consistent login and token model
- Ideal for CIAM and B2B scenarios
Limitations
- No complete isolation
- Common client and role structure
- Limited delegation of client administration
- Not suitable for widely divergent security policies
Comparison: Realms vs. Organizations
Scalability
| Criterion | Separate realms | Organizations |
| Isolation | Very high | Logical, not technical |
| Scalability | Limited with many clients | Very good |
| Operating expenses | Medium | Low |
| Shared clients | No | Yes |
| Client-specific IdPs | Yes | Yes |
| CIAM / B2B compatible | Limited | Very good |
| Regulatory separation | Well suited | Only to a limited extent |
Decision-making guidance from a business perspective
Separate realms are the right choice if:
- Clients must be strictly separated from one another
- There are various security, token, or compliance requirements
- Should be able to manage organizations independently
- Technical isolation is a priority
Organizations are the better choice when:
- There are many clients with similar requirements
- A central platform is operated
- The focus is on B2B SSO and CIAM scenarios
- Scalability and maintainability are crucial
In practice, a combination of both approaches is also common—for example, separate realms for internal and external identities, with organizations within the external realm for customer tenants.
Conclusion
With Keycloak 26.6, organizations have access to two mature models for tenant separation, each designed with distinct features. The choice between realms and organizations should not be based on ideology, but rather on architectural and use-case considerations.
While Realms provide maximum isolation, Organizations enable economically and organizationally scalable multi-tenancy—particularly for modern SaaS and CIAM platforms.
Making a well-thought-out architectural decision early on pays off in the long run in terms of operations, security, and future development.
