The usage of CockroachDB in newer security products is refreshing. I wonder if users could run one share a CRDB cluster between Zitadel and SpiceDB[0] to have a full, modern AuthN+AuthZ stack with few dependencies.
This seems very clean and handily beats keycloak there, at least.
I am building an application that will be deployed into a closed network, and it has some requirements regarding auth and authz that would be time-consuming(not to mention error prone) to implement. I also foresee there being a good chance of the customer wanting to integrate it with their existing stuff, so instead of having a custom user management system as part of the application, I ended up using keycloak.
So far, the experience has been .. okay. The beginning was kind of rough, and just recently there were some big changes, and some of the documentation is still out of date, and even more of the documentation is sort of .. meh. However, once I really started grokking both keycloak and the related authz concepts, it's been pretty smooth sailing since. There are some rough edges, like the nodejs admin client being somewhat janky(possibly auto-generated), but otherwise I would definitely use keycloak in other projects.
Zitadel seems like a very attractive alternative, and the documentation is stellar compared to keycloak's(at a glance at least, kudos for quickstart guides), but I'd still be sort of worried about the age and maturity of the project. Selling my customer on keycloak is relatively easy because it's not super young and being managed and actively developed by the folks at redhat. Selling them on zitadel would probably be harder.
Either way, best of luck. When there's a javascript client I might take this for a spin for a side project just to see how it compares to keycloak.
Appreciate the feedback and insights - thank you. Happy to keep you posted on the javascript client, this is for sure one on our list. Regarding user base, sure Keycloak is very mature and broadly used. We started our SaaS now over 1.5 years ago and continuously build on the feedback and the operational learnings.
We recently finished shipping a SCIM server implementation. It was a big lift (it's quite protean).
If anyone else wants to look at software supporting SCIM, this list seems like a place to start: http://www.simplecloud.info/#Implementations2 It lists both SCIM servers (which can be the source of truth for a set of users and groups) and SCIM clients (which can received CRUD requests from a SCIM server).
(I submitted our company to the list but I think they got caught up in the GitHub/Heroku situation, since changes in the GH repo don't seem to be going live: https://github.com/erdtman/simplecloud.info )
There is a SCIM plugin for Keycloak, though. We've made use of it and had a good experience. I'll have to dig up the Github project for it. I don't recall the name off the top of my head.
An wonderful piece of work. Note, however, that the most recent supported Keycloak version is 16.1.x. Whereas Keycloak has recently been reworked (beginning with 17.x, now at 18.x) around Quarkus. This is awkward to explain to stakeholders that understand the implications of having their authentication system held back due to dependencies.
SCIM is a well designed and standards based (RFCs even!) expression of identity management in REST. Expecting identity platforms to support it as a first class capability is reasonable.
This is interesting, but... how does one deploy this in a container without k8s (using Docker)?
Keycloak is big and complicated, but at least it's easy to hide all the complexity behind Docker. Other than configuring the database, one could treat it as an opaque blob.
Authentik is big and complicated and modular, so the complexity is apparent in the `docker-compose.yml`.
We're currently working on v2 with the goal to reduce that complexity. Goal is to make it easier to run a single binary, like you mentioned using Docker. Documentation for this is currently WIP - should be out end of May.
Firstly let me say that we like both Auth0 and Keycloak - as others have commented the solutions are widely used and have both unique advantages.
We built an open source alternative to Auth0 which fully supports self-hosting (today on K8s, soon as all-in-one binary on multiple platforms). Regarding Keycloak, it is a great project with high maturity and a lot of features, but lacks in support for B2B, cloud-native and manufacturer support. We wrote a blog comparing Auth0 and Keycloak in more detail, when you might want to consider ZITADEL as alternative. Hope that helps.
> Regarding Keycloak, it is a great project with high maturity and a lot of features, but lacks in support for B2B, cloud-native and manufacturer support.
Is this really true though? Last time I checked Keycloak was a RedHat project, meets the definition of cloud-native, and RedHat does provide RedHat Single Sign-On, a Keycloak-based service that is as B2B as it gets.
Also, further down the discussion you commented that the project doesn't even provide a Docker image, and instead you mention an ongoing rewrite that might provide a stand-alone binary.
Currently we provide a container image as well as K8s support.
The v2 will allow us to extend our support to a plain binary as well as serverless containers (Knative et. al)
Keycloak is a great tool but definitely not has B2B features like user management for each business customer, self service and delegated access management as well as self service federation.
If you feel that I am mistaken, feel free to point out the docs to that ;-)
> Keycloak is a great tool but definitely not has B2B features like user management for each business customer, self service and delegated access management as well as self service federation.
I might be misreading your post and/or the linked blog post, but I got the impression that both assume that different business customers will share the same KC realm and will only be divided by groups/roles/etc. Is that correct?
We use Keycloak in a multi-tenant scenario, so each new business customer spawns its own realm, meaning it can have a fully independent configuration (SSO, OAuth2 integration, 2FA, roles, etc.). While we provide a simplified UI in our product, a sufficiently technical customer can in principle be granted a realm-level administrator user to manage their own configuration.
From the IAM perspective (If the service is an IAM) I agree.
But as SaaS provider I don’t want to use multiple realms because in that case my client would need to understand multiple issuers.
Also Keycloak has a cutoff of around 400 ish realms last time I checked ;-)
I had to set up a OIDC server so our website could act as the OIDC provider, and I got really surprised how hard that is to do if you really need the most basic setup. In fact it seems that everybody would just keep a Keycloak or whatever— in their cluster and would keep it up-to-date with whatever user schema they would have in their app. This felt like too much work for me (I didn't want to maintain a whole extra service to just be able and provide a couple Oauth scopes from our API back-end.) so instead I went on and implemented the server directly in our app using https://github.com/zitadel/oidc. In fact this was the only fully-functioning OIDC implementation in Go that I could just plug in and make it work. So big props up to the Zitadel guys, the only worry would be from my side that the server implementation could be more generic and could rely on a set of interfaces that the users would be able to implement easily, without having to import a bunch of code from 'examples/server' like we have to do at the moment?
Thanks for the great feedback. I can see copy/paste issue of the server example. We'll definitely improve this in the future so you won't have to implement a lot of logic in the storage implementation.
When I checked this out 9 days ago there was a GitOps installation instructions page! I didn't have a chance to follow it up right away, but now it doesn't resolve anymore. What happened to GitOps support in Zitadel?
This looks great if you need it to scale but I would like a self contained version that works in a couple of docker containers and doesn’t need a cockroach db cluster in addition to a normal database. Anyway know of anything!?
> ZITADEL components send errors and usage data to CAOS Ltd., so that we are able to identify code improvement potential. If you don't want to send this data or don't have an internet connection, pass the global flag --disable-analytics when using zitadelctl. For disabling ingestion for already-running components, execute the takeoff command again with the --disable-analytics flag.
So, on by default spyware. How could anyone trust this in their infra when they are so shameless about exfiltrating data without consent?
> The flutter tool uses Google Analytics to report feature usage statistics and send crash reports. This data is used to help improve Flutter tools over time.
>
> Flutter tool analytics are not sent on the very first run. To disable reporting, run flutter config --no-analytics. To display the current setting, use flutter config. If you opt out of analytics, an opt-out event is sent, and then no further information is sent by the Flutter tool.
You do not seem to get it and that alone disqualifies your product for many admins in the EU.
To explain it clearly so you can better understand: you need to make ANY data submission OPT-IN, not OPT-OUT. That means that you need to ask users for consent before sending any data.
I strongly recommend doing this for a product that is in touch with any user data. For a product that would take such a central role in any infra your comments on this issue here are devastating - when you demonstrate ignorance for European data laws, how can any admin trust you with your product? Total self-destruct.
Thanks, good to know! Do you have chrome://flags/#enable-experimental-web-platform-features enabled by any chance? Seems to be an Docusaurus issue, we'll make an update.
Great. Would love to hear more about your impression and the comparison to Okta. Okta is for sure very mature. Some users who switched liked the fact that you can run ZTIADEL on any infrastructure (self-hosting) as well as the self-service in B2B scenarios (which is ticket-ops when doing it with Okta, apparently). Hope this helps.
Yeesh, that name! What the heck were they thinking? "Hey, what if we combined Zit and Citadel!"
But seriously, now I want to know, what are the most unfortunate technology or startup names my fellow HN'ers have encountered? I'd bet a moderate sum there are some wild examples to be found in SV history.
> what are the most unfortunate technology or startup names my fellow HN'ers have encountered?
A few years back there was a Github OSS project by an Asian developer who couldn't speak English at all - I think it was a Ruby or Node utility library of some kind.
I don't remember the exact details anymore, but he intended to call it something like 'childlike' or 'so simple a child can use it' - unfortunately the machine translator he used interpreted the input phrase in his language as 'one that likes children'.
So he was very, very confused at the loud community reaction when he made a post announcing the 0.1 release of his new 'pedophile' library.
Zitadel: Popping the competition! (Sponsored by Clearasil)
Honestly, how does this name even remotely relate to what it does? Sometimes I really despise the trend towards "quirky" names in open source projects.
It was named after "Mongo, an immensely strong, dim-witted, yet philosophical henchman" in the movie "Blazing Saddles" (which is hilarious but would probably get Mel Brooks burned at the stake if he tried to make it today.)
Anyway, "mongo" is short for "mongoloid" which was a derogatory word for folks with what we now call Down Syndrome, and also racist in re: Mongols. So yeah, not a great choice of name.
I've heard of "mong" as short for "mongoloid" but I've never heard of "monogo" being used that way. Searching through Google books most of the results for mongo refer to the Mongo people of the Congo. The second most common source is the fictional planet Mongo from the Flash Gordon comics.
[0]: https://github.com/authzed/spicedb