Compared with Ory?

[Davincible]

I just stumbled upon Zitadel, and I was curious how Zital is different/the same to Ory's projects.

Zitadel seems to be newer, thus I am curious what the motivation was for Zitadel.

[fforootd]

Hi There

I am happy to hep here.
Please take it with a grain of salt since its our/my view 😁 and I am not the Ory heavy user!

TL;DR

• ZITADEL: If you want turnkey solution built for the cloud with a great support for B2B, a strong audit trail and self-hosting, but also the option for SaaS
• Ory: If you want flexibility to customize all the stuff but are aware that it is not as turnkey as ZITADEL

What is different

• ZITADEL is created to be a platform where user can mix different cases. For example you can do B2C, B2B and Machine to Machine (M2M) with the same Authentication and Authorization system which reduces the number of involved system. Ory is more geared toward B2C case it seems
• ZITADEL brings a delegated access management along which allows you to creates B2B apps without the need to create the delegation on your own
• ZITADEL has all the self-service logic available for B2B customers to manage their users, define policies, assign access as well es setup SSO on their own. Without the intervention of you
• ZITADEL brings along a customizable login/register instead of building your own on a set of templates as Ory does approach this
• ZITADEL uses an event storing architecture to create an unlimited audit trail of all changes that happen on each object. Ory stores the object in their database and I am unsure how they to audit logs
• ZITADEL only uses well established protocols for Authentication like OpenID Connect. Ory also can handle OIDC but I think their main way of integrating first party clients is through the use of a cookie mechanism
• ZITADEL uses a concept called actions to allow users to run js code based on ZITADELs events to customize the behaviour of ZITADEL.
• ZITADEL is shipped as one binary that includes all the features and components. Ory separated their components into different binaries
• ZITADEL provides gRPC, gRPC-web and Rest API to allow for developer freedom. Ory mainly uses Rest.
• Both follow an API first mantra
• Both use Go as Backend Language
• ZITADEL uses Angular while Ory uses React for some guys
• Both are working on SAML 2.0 Support (Although i believe with different goals)
• Ory currently supports more Databases. ZITADEL supports CockroachDB and soon Postgres
• ZITADEL is optimized to be used on Kubernetes or Knative (Google Cloud Run, et. al.). Not sure about Ory here
• Both are Apache 2.0
• ZITADELs Cloud version is the exact same version as the OSS. Not sure about Ory here
• ZITADEL provides an official Terraform provider. Ory has an unofficial one

That's it from the top of my head

[fforootd]

Maybe @hifabienne, @livio-a or @adlerhurst want to provide something more

[mffap]

Regarding motivation maybe something to add: The team behind ZITADEL worked in the government sector before. There were many different parties, such as agencies, county administrations, etc., that want to gain access to different services across many different organizations. Solving the challenges around the issue of delegated access management was key to that solution (instead of a manual/ticket-ops approach). To solve this problem, which is actually not limited to gov-to-gov, amongst other things, we created ZITADEL. At the core is the organizational model for multi-tenancy with loads of support for self-service.
You can also read a bit more on the background here: https://www.producthunt.com/posts/zitadel

Maybe also have a look at the discussion around Ory, Keycloack and ZITADEL here: https://news.ycombinator.com/item?id=31259645

[Davincible]

Thanks A lot for the detailed (and quick) replies !!

Sounds like ZITADEL would be really nice to work with. I particularly like the turnkey aspect as you described.

I'm looking forward to trying it out once the Postgres integration is merged!

One small side question;
Does ZITADEL OSS by default come with a front-end? As Ory does not (besides from a template).

For more complicated setups a custom implementation would be used. But for a quick Traefik forward-auth it'd be nice to have a simple front-end included

Edit: Since you mentioned Cloud and OSS offering is the same, I suppose the UIs on the readme are included :D

[fforootd]

Does ZITADEL OSS by default come with a front-end? As Ory does not (besides from a template).

Yes ZITADEL brings along a Login/Register/Self-Service and Management GUI with Customization options.

Edit: Since you mentioned Cloud and OSS offering is the same, I suppose the UIs on the readme are included :D

Yes 😁 and we outline some of the SaaS benefits here.

The only piece that is currently not inside ZITADEL is our customer portal, through which you can create ZITADEL instances in the ZITADEL Cloud

[aeneasr]

Hey, thank you for the comparison! I think it's great that there is more movement in the open source identity world :)

Making comparisons of open source projects is always difficult. But I do want to set the record straight on some of the points made above, to properly reflect what Ory is.

Ory: If you want flexibility to customize all the stuff but are aware that it is not as turnkey as ZITADEL

Ory Cloud is our turnkey solution, where as Ory Open Source has more possibilities (e.g. wrt to deployment) and thus more work to set up yourself at scale.

1. For example you can do B2C, B2B and Machine to Machine (M2M) with the same Authentication and Authorization system which reduces the number of involved system. Ory is more geared toward B2C case it seems
   ZITADEL brings a delegated access management along which allows you to creates B2B apps without the need to create the delegation on your own

Ory fully supports OAuth2 with a variety of advanced specs, OpenID Connect ("delegated access management"), Identity Management, and Permissioning based on Google Zanzibar. You can run any use case you want :)

ZITADEL brings along a customizable login/register instead of building your own on a set of templates as Ory does approach this

Ory has templates available you may use to customize the login/registration screen. We're also working on full customizability and components for Angular, React, Vue, and other popular frameworks.

ZITADEL only uses well established protocols for Authentication like OpenID Connect. Ory also can handle OIDC but I think their main way of integrating first party clients is through the use of a cookie mechanism

I recommend reading the following articles as to why that is:

• https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/
• https://www.ory.sh/docs/hydra/concepts/before-oauth2

We still have a fully certified OpenID Conenct OP capabilities. To make the one comparison here: Zitadel is not certified according to the README).

ZITADEL provides gRPC, gRPC-web and Rest API to allow for developer freedom. Ory mainly uses Rest.

This is partially true. I'm not sure how ZITADEL solves OAuth2 APIs, but according to spec those are REST first and do not have gRPC definitions. Ory's Permissioning Service is gRPC-first. Our identity system is REST only, and we are thinking about making the admin APIs gRPC-enabled.

ZITADEL is optimized to be used on Kubernetes or Knative (Google Cloud Run, et. al.). Not sure about Ory here

Of course we're optimized for Kubernetes and ship tons of tooling:

• https://github.com/ory/k8s
• https://github.com/ory/hydra-maester (CRD controller)
• https://github.com/ory/oathkeeper-maester (CRD controller)

ZITADEL is shipped as one binary that includes all the features and components. Ory separated their components into different binaries

That is true, and in my opinion a strength of the ecosystem. If you need to become an OpenID Connect provider, but already have a user management in place, use this one service only. Need it all? Use all of them! This makes the systems more generic and targeted at scale.

In summary, I think the systems are solving similar use-cases, with Ory targeting a broader spec of topics:

• Identity Management
• Permission Management
• Delegation Protocols and SSO
• Zero Trust and End-To-End Security

In terms of experience one difference I'd say is that if you want a more Keycloak-esque experience, you'd probably use ZITADEL: built-in templating, js-plugin system, one system for everything.

If you want a more API / cloud-native driven approach, use Ory: API-based ui system, RPC based plugin system, compartmentalized and domain driven design.

Enjoy both projects :)

[fforootd]

If I understand correctly, the organization model is mostly about managing multiple tenants in the same organization, in the same process (and most likely the same database). Ory orchestrates this differently as we do not have multi-tenancy code in the codebase but instead are asking DevOps to run multiple processes linked to separate databases for physical data isolation and high security (vs row-level security).

Well that's where we diverge in that case. However I would not go so far and call database separation "high security" since this implies that row level is bad by design 😉.

Out of curiosity and a little off-topic, how many DBs can you run in your Cockroach Clusters. Last time i checked this was somewhat of a concern.

ZITADEL solves the IAM problem in a similar way to Keycloak - what Keycloak calls realms ZITADEL calls organizations and projects (as far as I can tell). At Ory we don't have such a concept and it is up to the implementor to decide what organizational model to use (if any). In our cloud system all of this is automated of course, making it much easier to start a new project/tenant/environment using a simple REST call :)

Its true that we aim towards replacing Auth0 and Keycloak.

Keep up the good work, maybe we can merge ory/fosite and zitadel/oidc, as it looks like those two fit well together from scope/implementation/use case :)

Would be definitely be better for the Go ecosystem. I think at least providing a default OIDC lib inside the language could be of use at one point. TBH at least our capacity is somewhat limited at the moment 😁

[aeneasr]

Well that's where we diverge in that case. However I would not go so far and call database separation "high security" since this implies that row level is bad by design 😉.

RLS in CRDB is hard to pull of, because CRDB does not have RLS. You thus only rely on the software layer for isolation which is problematic if the code is not properly audited / tested. Not saying that that's the case here, it's just a risk factor one has to calculate in when using this design pattern.

Out of curiosity and a little off-topic, how many DBs can you run in your Cockroach Clusters. Last time i checked this was somewhat of a concern.

Looks like you found my issue in CRDB :) They resolved issues with excessive range use for multiple DBs!

[fforootd]

RLS in CRDB is hard to pull of, because CRDB does not have RLS. You thus only rely on the software layer for isolation which is problematic if the code is not properly audited / tested. Not saying that that's the case here, it's just a risk factor one has to calculate in when using this design pattern.

I agree while RLS should not be the only concern of a multi tenant system.

Looks like you found my issue in CRDB :) They resolved issues with excessive range use for multiple DBs!

Hm no, not really. Care to link? We had this from talk with CRDB where the ultimate question was "how many DBs can CRDB handle"

[dm17]

It would be great to hear some conclusions and experiences of those who have compared and contrasted these considering their last two years of changes since the last message here. To me, at this more it seems Zitadel more confidently supports impersonation (the feature) versus Ory. The customizability of Zitadel is still a concern when researching the features of Ory. I'm curious about which identity managers today work best in the HTMX paradigm.

[fforootd]

Good question 😁

I think Zitadel evolved quite a lot since this chat.
For example, while we do not have htmx we just released a first version of a typescript based login that people can fork and tweak.