What makes ZITADEL a great Keycloak alternative
Founder and CEO
- What is Keycloak and ZITADEL?
- What do Keycloak and ZITADEL have in common?
- What differentiates Keycloak and ZITADEL?
- Conclusion Keycloak vs. ZITADEL
Quite often we get the question: “Why should we choose ZITADEL over Keycloak?”. This article tries to shine some light on this question. We will explain what both systems have in common and why you should consider ZITADEL as a Keycloak alternative.
What is Keycloak and ZITADEL?
What is Keycloak
Keycloak is one of the most widely used Open Source Identity and Access Management. It forms the base for the commercial solution “Red Hat Single Sign-On”. Keycloak is mostly maintained by the community. It brings functions like identity-brokering, multi-factor / passwordless authentication, access management, OpenID Connect, OAuth 2.0, SAML 2.0 and to some degree multi-tenancy.
What is ZITADEL
ZITADEL is the identity experience platform built for developers and security officers due to its easy integration into your project and high level of audit capabilities. The main contributor is the company called CAOS from Switzerland. ZITADEL does support features like identity-brokering, B2B multi-tenancy, multi-factor / passwordless authentication, delegated access management, in-context audit trail, OpenID Connect, SAML 2.0 and OAuth 2.0.
What do Keycloak and ZITADEL have in common?
Common Features
Both systems provide a great bunch of features out of the box. These features help you build secure applications for most of your needs. Be it mobile, web or native applications. Using a ready made identity and access management system reduces your time spent and risk of implementing security related features.
- A login, register and reset interface with custom branding
- Self-Service capabilities for the user, to change his password and factors
- A wide variety of multifactor options for second factor or passwordless authentication
- WebAuthN with FIDO2 and U2F
- OTP (TOTP, HOTP)
- Single Sign on across multiple applications
- Access Management for your applications
- Identity Brokering and Social Login Capabilities
- Support for Federation with OpenID Connect and SAML 2.0
- Authorization with OAuth 2.0
- Adapters and SDKs in multiple languages
- Authentication with LDAP
Open Source
Keycloak and ZITADEL are both published with an Apache 2.0 license on GitHub and are totally free to use without restrictions. It might seem odd that both projects publish their code and essentially give it away for free. We believe the transparency and openness of such a project helps build trust into both solutions.
Operations
If you would like to run either Keycloak or ZITADEL on your own infrastructure you can easily go ahead and do so without jumping the hoops. There are some differences between the systems how they achieve this but more to this later. Both Keycloak and ZITADEL supply a custom built operator for Kubernetes to install and operate the IAM. This includes features such as backup and restore, creation of resources, updates, monitoring and so on.
What differentiates Keycloak and ZITADEL?
Features
Audit Trail
One of the big differences between Keycloak and ZITADEL is how data is stored. Keycloak relies on a stateful approach to store IAM resources, like users, roles, and so on in its database. This design choice restricts you from analyzing directly which resources were changed and what in fact has changed. Instead you need to rely on the correctness of a segregated audit log. Audit logs need to be configured on your own and are stored in the database. Establishing an unified audit trail across multiple products that rely on Keycloak is cumbersome.
ZITADEL, on the other hand, embodies the concept of event sourcing and CQRS to achieve a complete audit trail of all the IAM resources. With this you can travel back in time to see how an object was looking at any point in time. This is because every operation is stored in events. You may think of it as storing the diff/delta of each operation in an “append-only log” and all audit needs are covered from the ground up.
As an added benefit, the data stored in events can be used to improve current and even future threat models with past data. It also enables you to build reports, for example usage of a client, over a long period of time.
Multi Tenancy
Keycloak’s tenancy model is built around the idea of realms as means of separation of concern for close to all resources, including users, clients, roles, policies and so on. This allows admins to create multiple independent realms with close to none interaction between them.
ZITADEL is organized around the idea of organizations. Organizations are a vessel for users, policies, and projects. You can use projects within your organization to manage the security context of closely related components, such as roles, grants and authorizations for multiple clients. You can set up multiple projects within your organization.
ZITADEL’s organization oriented model allows you to easily create multiple organizations and manage them with the same user with the necessary management roles. This also allows for great self-service processes which help you reduce your effort.
More details about organization and projects can be found on our documentation page.
Projects with multiple applications
With Keycloak you manage clients and configure them to map roles and other resources afterwards, which makes managing multi-client projects that share the role catalog hard.
We have introduced the concept of projects in ZITADEL making it easier to manage multi-client projects. A project holds all the OpenID Connect, SAML 2.0, and OAuth 2.0 clients who share a common authorization catalog, in most cases roles.
Example: Imagine a service like Google Drive that offers you different clients, such as web, mobile, desktop where all share the same authorization foundation. Being able to bundle different applications and their shared authorization context is why we introduced projects.
User and access management for B2B SaaS applications
The need to allow customers to manage their own users and corresponding access rights, restricts Keycloak’s usability for projects with strong business to business (B2B) requirements.
Keycloak offers a workaround through fine-grained permissions in combination with groups. However such a workaround is most often cumbersome for the administrator. Furthermore Keycloak does not allow for easy branding, such as logos, colors, or texts, and other customization (eg, domains) for certain groups, in this instance different B2B customers of the service.
With ZITADEL’s organizations it is possible to let B2B customers and partners self-manage their users, access rights and even SSO options as well as security policies. You can simply create an organization for each customer or partner and give them the ORG_OWNER manager role. In combination of being able to delegate access management to those customer organizations, this becomes a powerful capability to manage B2B customers at scale.
Delegate the access management to your customers or partners
ZITADEL lets you delegate the access management between organizations. This means you can select a subset of roles for a given project and allow the granted organization to self-manage those roles for their users.
Delegated Access Management is a highly useful feature for SaaS companies that have some sort of organization as customers, for example a B2B software provider. The SaaS provider wants to delegate the ability to manage access for certain roles of my service to customers or partners.
To give a specific example, ACME may grant the project “Customer Portal” to a customer’s organization and make a user manager of the organization. With this setup, the customer can independently assign roles such as “portal viewer” to users with her organization.
The owner of the project, role and the grant will always be the SaaS provider and hence we can remove the grant anytime, for example when a customer terminates a contract.
Keycloak on the other hand does not really allow for an easy delegation of the access management to different realms. There is no easy way or documented workaround for this that we are aware of.
You can find more information about the B2B scenario in our documentation or try out our example application.
Extensibility
Keycloak allows you to run your own code within its codebase, a feature called service provider interfaces (SPI). The impact on the operational security, quality of a unified audit trail, and on the ability to upgrade your system will be directly tied to the quality of those extensions.
After all this is a tight coupling of your code and the Keycloak functions. We believe that this tight coupling of third party components has the disadvantage that whenever a new Keycloak version is published the custom code needs to be tested.
Another drawback is that you are limited to Java as a possible language to implement custom code.
We designed ZITADEL in a way that allows loose coupling of additional components.
ZITADELs APIs, built with gRPC and REST, enables you to integrate your project's special requirements. For example you could build your own onboarding module or integrate your business process from service now without a tight coupling. We also provide client implementations for popular frameworks and languages.
Actions allow you to execute custom code based on triggering events. The code is executed in a sandbox environment during runtime. For example you could add custom claims to a token after authentication. At the moment we support custom code in JavaScript. Actions can also be used for a push style integration pattern.
Connecting external systems like LDAP
In contrast to Keycloak, ZITADEL does not directly connect to external systems like a LDAP to manage users, because we want to keep the coupling to external systems as low as possible. We rely on a pattern called the “connector pattern” to integrate user management of such external systems. Which means that we supply customers with a customizable agent that connects to these systems directly in your networks. So you don’t need to expose your internal systems more than needed. For self-hosting users we provide an LDAP IDP template for LDAP Binding Authentication.
Machine-to-Machine Communication
Keycloak has only limited support for M2M communication. Each client has a built-in service account that can be activated. The service account is linked to a specific client and doesn’t support refresh tokens.
In ZITADEL you can create Service Accounts to be used for M2M communication. You can authorize Service Accounts to projects, even granted projects, or assign Management Roles, like you do with other users. A Service Account authenticates with JWT Profile or through a personal access token.
Product and Cloud Service
Cloud Service
In contrast to Keycloak we supply a cloud service built with ZITADEL to its customers called ZITADEL Cloud. Furthermore you can get a managed instance or a support contract from ZITADEL.
With Keycloak you can choose from a wide variety of companies offering services around Keycloak. From managed instances to extensions. Red Hat does offer “Red Hat Single Sign-On” with a quote pricing.
Maintenance and security
Keycloak has a highly active community and many contributors that improve the project continuously. The project has an established security policy and some of its users sponsor and publish penetration tests occasionally. Users are generally dependent on community support to fix critical issues.
ZITADEL is developed and maintained by CAOS. We provide ZITADEL as Service and a support program for customers who self-host ZITADEL. Thus we have staff handling security patches and bug fixes reported by our customers with highest priority. This maintenance is directly released to the Open Source version of ZITADEL.
Product Management
Both projects develop in the open, have a public roadmap, and communicate with the community out in the open.
Shaping ZITADEL’s roadmap and prioritization of features is done by ZITADEL Staff. We welcome feedback from the community on our roadmap and we are happy to accept upstream pull requests for ZITADEL.
In case you can’t contribute directly to the open source version of ZITADEL, but want to accelerate development, we may develop the feature on request.
Operations
Deployment and Technologies
We built ZITADEL with Go and Angular to run on a lot of different platforms and operating systems. As of today we primarily run ZITADEL in Kubernetes environments and also Serverless offerings like Google's Cloud Run. ZITADEL stores all its states within its database so that it is easy to deploy. Basically you only need a database and the ZITADEL binary to create a great service. We also optimized it to run behind web application firewalls (WAF) and content delivery networks (CDN) to help scale and protect the service.
Keycloak can run on different systems as well but it needs to have Java as a prerequisite. Persistence is achieved with Quarkus and Wildfly persistence options based on Hibernate and it also uses Infinispan as a cache layer which has some challenges (see below) when running in container environments. The APIs are mainly in a REST fashion and are easy to integrate.
We have not yet seen a Keycloak Serverless based deployment, even though we think it could be feasible. Even if the resource footprint is higher when compared to ZITADEL.
Scaling
Scaling ZITADEL is easy to achieve, because ZITADEL relies on CockroachDB to handle replication of the shared data. To further improve the performance we rely on concepts like a ring buffer in the ZITADEL application which does cache the latest events from the evenstore. This is easy to scale because the events are appended only. To achieve great query performance we use optimized query models which are also stored in the database. With CockroachDB you also have the possibility to define which data are stored where. You can restrict certain data to a node, datacenter or region. Whatever fits your use case and risk model.
When you need to scale Keycloak you need to use an external database supported by Keycloak (Hibernate). Most of them do not scale as easily as CockroachDB, this is especially a concern across data centers and regions. Furthermore Keycloak relies on Infinispan as a cache layer which has some degree of operation overhead to it. This means you also have to operate and scale the cache.. The project seems to plan support for databases such as CockroachDB and running without Infinispan for smaller deployments.
Keycloak does not support zero-downtime deployments due to its architectural design, but there is ongoing work to solve this.
Additionally Keycloak does not work well in scenarios where one has more than around 400 realms. There is a fixed memory cost for each realm and it can get really resource hungry or slow quite fast.
More information about how ZITADEL benefits from CockroachDB can be found in our livestream with the Team of CockroachDB.
Conclusion Keycloak vs. ZITADEL
Keycloak is a mature, feature packed and proper open source IAM. It lacks some focus towards cloud native concepts and is not exactly easy to operate and scale. The multi-tenancy and audit features are not geared towards the needs of SaaS projects.
ZITADEL is a young, high velocity project that addresses the needs of SaaS projects by providing easier scalability with cloud native concepts, low coupling and a complete audit trail. It powers the IAM-as-a-Service which offers a free tier. It is also possible to run your own ZITADEL either by utilizing the open source version or by reaching out to CAOS who is happy to offer their services and talk about your cases.
Disclaimer
The information for this comparison was retrieved on February 28, 2022. The article was last updated on March 13, 2023 with further links and implementation details around LDAP.
Does something seem outdated or not valid? Please let us know.