Keycloak vs Auth0 vs Ory vs Zitadel: Architectural Trade-offs and Pricing

The Identity Infrastructure Decision

For architects, selecting an identity provider (IdP) is rarely about finding a feature gap; it is about deciding where the operational boundary lies. The market is currently split between four distinct approaches: Keycloak and Zitadel offer self-hosted, customizable control; Auth0 provides a fully managed, SaaS-centric experience; and Ory offers a composable, API-first infrastructure layer. This decision impacts your deployment topology, your monthly burn rate, and your ability to scale authentication independently of your application logic.

Architecture: Monoliths vs. Composable Microservices

The fundamental difference between these platforms lies in how they structure their code and data.

Keycloak, the most mature open-source option, operates as a Java-based monolith. It bundles authentication, authorization, user federation, and administrative UI into a single deployment unit. While this simplifies initial setup (a single JAR or container), it creates a rigid scaling model. To handle increased authentication load, you must scale the entire application, even if only the login endpoint is under pressure. This monolithic nature is well-documented in Red Hat’s Keycloak documentation, which notes that vertical scaling is often required before horizontal distribution can be effectively implemented via clustered nodes [1].

# Keycloak typical deployment
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:latest start-dev

Ory takes the opposite approach. It decomposes identity into specialized microservices: Hydra for OAuth 2.0/OIDC, Kratos for identity management (login/registration), Oathkeeper for access control, and Keto for authorization. This allows you to scale Kratos independently if you have high registration volume, while keeping Hydra stable. However, this increases infrastructure complexity significantly. You are no longer deploying one service; you are orchestrating a small cluster. The ory vs zitadel debate often centers on this trade-off: Ory’s granular composability versus Zitadel’s cohesive simplicity.

Zitadel positions itself between these extremes. It is self-hosted but built on a modern Go stack with a CQRS (Command Query Responsibility Segregation) and Event Sourcing architecture. This allows for better horizontal scaling than Keycloak’s monolith while remaining more cohesive than Ory’s fragmented suite. Zitadel’s architecture is designed to handle high write-throughput scenarios by separating command processing from query responses, a pattern described in their official architecture guide [2].

Self-Hosting: Operational Burden vs. Control

If you choose self-hosting, you are buying control at the expense of operational overhead.

Keycloak is the de facto standard for self-hosted IAM. Its strength is community adoption and extensive documentation. However, upgrading Keycloak often requires manual database migration steps that can be fragile. Managing High Availability (HA) requires configuring distributed caching (e.g., Infinispan) and ensuring sticky sessions or proper session replication, which adds configuration drift.

Zitadel argues that modern self-hosting should be easier. It uses a clean SQL schema (PostgreSQL/MySQL) and avoids the complex migration scripts common in older Java frameworks. Its admin UI is embedded but configurable. For teams wanting full data residency without managing a Java EE ecosystem, Zitadel is a strong contender.

Ory requires the most DevOps maturity. You must manage the underlying infrastructure for multiple services, their dependencies (PostgreSQL, Redis, Kafka for Ory Hydra), and their inter-service communication. However, Ory’s API-first nature means you can script the entire identity lifecycle. There is no "Admin UI" to log into for end-users; everything is done via REST/JSON. This is ideal for programmatic identity management but painful for non-technical stakeholders who need to manually approve users.

Auth0 removes this burden entirely. You do not manage servers, databases, or upgrades. You configure rules and hooks in their dashboard. The trade-off is vendor lock-in. Auth0’s ecosystem includes proprietary "Rules" and "Hooks" that are difficult to port to other IdPs. As noted in various community migration guides, relying on Auth0-specific JavaScript execution contexts can create significant technical debt if you need to migrate away [3].

Pricing: MAUs vs. Infrastructure Costs

Pricing models dictate the long-term financial trajectory of your identity strategy.

Auth0 charges per Monthly Active User (MAU). This seems simple but can become expensive at scale. For B2B applications where a single corporate user might generate hundreds of sub-account authentications, Auth0’s definition of "active user" can lead to unexpected bill shocks. Additionally, premium features like advanced SCIM provisioning or custom domains require higher-tier plans.

Keycloak is free. The cost is entirely internal: engineers’ time spent maintaining the infrastructure, security patching, and monitoring. For a large organization with 100k+ users, the infrastructure cost (AWS RDS, EC2/ECS) might total $500–$1,000/month, but the engineering hours can exceed that. Understanding iam pricing strategies here involves calculating the total cost of ownership (TCO), including salary and downtime risks, rather than just the software license.

Ory offers a "Bring Your Own Cloud" model. The software is open-source (Apache 2.0). You pay for the infrastructure you run. Ory also offers a managed service, Ory Network, which has a free tier and paid tiers based on MAUs, similar to Auth0 but often with more granular pricing for API calls. This flexibility allows startups to self-host for free and migrate to Ory Network when they need SLAs. When evaluating ory vs zitadel from a cost perspective, Ory’s pay-per-API-call model can be more predictable for sporadic traffic, whereas Zitadel’s resource-based pricing may be more stable for constant high-volume workloads.

Zitadel follows a similar open-source model. The core is free. They offer a hosted version with pricing based on seats and MAUs. Their self-hosted version is designed to be resource-efficient, requiring less memory than Keycloak’s JVM, potentially lowering infrastructure costs.

Feature Comparison: Standards Compliance

All four platforms support OIDC and OAuth 2.0, the modern standards for authentication and authorization. However, their implementation depth varies.

FIDO2/WebAuthn: Keycloak and Zitadel have robust, out-of-the-box support for passwordless authentication via WebAuthn. Ory supports it via Kratos but may require more configuration to integrate with hardware keys. Auth0 supports it but often treats it as an additional add-on or requires specific tenant configurations.

User Provisioning (SCIM): If you need to sync users from an IdP to downstream apps (or vice versa), SCIM is critical. Auth0 has strong SCIM support for enterprise integrations. Keycloak requires community adapters or custom scripts for some legacy systems. Zitadel has built-in SCIM support, making it a strong choice for B2B SaaS companies needing automated user onboarding.

Authorization: Keycloak uses its own policy enforcement points (PAP/PEP) which can be complex to integrate. Ory’s Ory Keto and Oathkeeper offer a more granular, policy-as-code approach, suitable for complex microservice architectures where fine-grained authorization is needed beyond simple roles.

Recommendation

Choose Keycloak if you need a proven, feature-rich solution, have existing Java expertise, and want to avoid vendor lock-in. It is the safest default for most enterprises.

Choose Auth0 if you lack DevOps resources, need to launch quickly, and have the budget to pay for convenience. It is best for companies where identity is not a core competitive advantage.

Choose Ory if you are building a highly scalable, API-driven platform and want to compose identity services like Lego bricks. It is ideal for engineering-led organizations that prefer code over UI.

Choose Zitadel if you want a modern, self-hosted alternative to Keycloak with better scalability and easier operations, particularly for B2B scenarios requiring SCIM and multi-tenancy.

Conclusion

The choice between Keycloak, Auth0, Ory, and Zitadel is not a feature comparison but an infrastructure ownership decision. Architects must trade off operational complexity (Keycloak/Zitadel self-hosted) for managed convenience (Auth0) or API-first composability (Ory). By aligning the platform’s architectural pattern with your team’s DevOps maturity and long-term scaling needs, you can select an identity provider that supports rather than hinders your growth. Furthermore, when finalizing the decision, consider the total iam pricing structure, including hidden costs like engineering maintenance time and migration risks, to ensure the chosen platform aligns with both technical and financial goals.

[1] Red Hat. (2023). Keycloak Architecture and Deployment Guide. Retrieved from https://www.keycloak.org/docs/latest/server_development/#_architecture [2] Zitadel. (2023). Zitadel Architecture: CQRS and Event Sourcing. Retrieved from https://docs.zitadel.com/docs/guides/architecture [3] Auth0 Community. (2022). Migrating Away from Auth0 Rules and Hooks. Retrieved from https://community.auth0.com/t/migrating-away-from-auth0-rules-and-hooks/