Keycloak vs Zitadel
Keycloak against Zitadel for customer and workforce identity: Apache-2.0 against AGPL-3.0, realms against organizations for multi-tenancy, event-sourced audit trail, database options and operating effort.

Comparisons anchored on Keycloak, the Apache-2.0 CNCF identity and access management server: against Zitadel, authentik, Authelia, midPoint and FreeIPA.
Keycloak against Zitadel for customer and workforce identity: Apache-2.0 against AGPL-3.0, realms against organizations for multi-tenancy, event-sourced audit trail, database options and operating effort.
Keycloak against authentik: protocol coverage (authentik adds LDAP, RADIUS and proxy providers), Apache-2.0 against MIT with a paid enterprise directory, Kubernetes operator against Helm, and fit for enterprise versus smaller teams.
A full identity provider against a lightweight reverse-proxy authenticator: Keycloak's SAML, federation and admin console against Authelia's forward auth, OpenID Certified OIDC and file or LDAP users.
Why Keycloak (access management and SSO) and midPoint (identity governance and provisioning) solve different problems, when you need one or both, and how they connect.
Web SSO with Keycloak against Linux identity with FreeIPA: OIDC and SAML for applications against LDAP, Kerberos, certificates and host policies for servers, and the common pattern of federating Keycloak to FreeIPA.
The three most shortlisted open source identity providers side by side: licenses and paid editions, protocols, multi-tenancy, databases and deployment, and which fits workforce SSO, B2B SaaS or a small IT team.
How each models tenants for B2B products: Keycloak realms and its Organizations feature against Zitadel instances and organizations, per-customer identity providers, and admin delegation to customers.
What Zitadel's 2025 move to AGPL-3.0 means next to Keycloak's Apache-2.0: obligations when you modify or embed the server, which Zitadel parts stay Apache-2.0, and when a commercial license matters.
Whether to run Keycloak on Kubernetes with the Keycloak Operator or from the server distribution on virtual machines. Covers what the Operator installs and leaves to you (the database), how cluster discovery works in both, the experimental Helm chart, upgrade and downgrade limits, and the platform skills each route needs.
Which Keycloak high availability architecture to build: one cluster spread across availability zones, or the multi-cluster v2 design that links independent sites without an external Infinispan cluster. Covers latency and database requirements, the external load balancer, tested sizing, failover downtime and the deprecated v1 design to migrate away from.
A widely adopted Apache-2.0 Java IAM server with SAML, OIDC, LDAP federation and an admin console, against Kanidm's MPL-2.0 Rust identity platform that bundles OAuth2/OIDC, passkeys, RADIUS, Unix login and a read-only LDAPS gateway but has no SAML. Covers database and HA design, admin tooling, release support windows and which fits enterprise SSO versus Linux-heavy estates.
A full identity and access management server with its own user store, realms, admin console and SAML, against Dex, the CNCF Sandbox OIDC broker that keeps no users and only federates LDAP, GitHub, OIDC and other upstreams. Covers Kubernetes and kubectl sign-in, storage, connector maturity including Dex's unmaintained SAML connector, and when a platform team needs Keycloak instead of Dex.
An all-in-one IAM server with admin console against Ory's headless, API-first components (Kratos, Hydra, Keto): both Apache-2.0, but SAML, SCIM and organization login sit in Ory's paid Enterprise License builds, which changes the comparison for B2B SSO.
Two Apache-2.0 Java identity servers compared: protocols (SAML, OIDC, SCIM, WS-Federation), user stores, B2B CIAM features, and the difference between Keycloak's community releases and WSO2's unsupported open source distribution versus paid subscription builds.
Why this is usually not either-or: an SSO and federation server against an LDAPv3 directory. Covers what each stores and serves, Keycloak's LDAP user federation, and when a directory alone is enough.
Three self-hosted identity platforms for customer-facing apps compared: licenses (Apache-2.0, AGPL-3.0 core, Apache-2.0 with paid enterprise builds), multi-tenancy, SAML and SCIM availability, databases and hosted login versus headless UI.
Upstream Keycloak against Red Hat's supported distribution: the documented differences (artifacts, bundled database drivers, GELF logging), version matching rules for moving an existing deployment across, and when a Red Hat subscription is worth paying for.
Keycloak against Casdoor, the Apache-2.0 Go identity server with a web console: protocol coverage including CAS and RADIUS, multiple organizations per instance, database choices, Casdoor Cloud versus self-hosting, and which fits an enterprise SSO hub or a lighter multi-org app.
Keycloak against Logto for teams adding login to a SaaS product: licensing (Apache-2.0 vs MPL-2.0), OIDC, OAuth 2.1 and SAML support, organizations for B2B tenants, the single-admin limit of self-hosted Logto and what each costs to run.
The developer CIAM shortlist: Keycloak, Logto and Zitadel compared on license, multi-tenancy model, SAML and SCIM support, self-hosting requirements and managed cloud options, with a verdict by scenario for B2B SaaS, consumer apps and internal SSO.
Two ways to connect Keycloak to existing identities: LDAP or Active Directory user federation, where Keycloak reads the directory, versus brokering logins to an external OIDC or SAML provider. Covers where passwords live, MFA, provisioning and when to combine both.
For teams whose legacy apps speak only LDAP: authentik's LDAP provider exposes users to those apps, while Keycloak federates users from an LDAP or Active Directory directory. Explains which direction each supports and when a separate directory is still needed.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.