As a possible alternative, I've recently started using Zitadel (https://zitadel.com/) which is a very full-fledged open source IDP, in active development.
This looks very interesting, I have recently tried using auth0 and was so horribly disappointed with how you go from 0 to enterprise as soon as you need any modern security feature. Plus I had assumed that they had a mature product, but is chaotic and difficult to know what you are doing for even the simplest use cases.
Wow Zitadel looks absolutely amazing. All the features you want out of login, permissive license, good pl choice, easy to deploy, postgres-first.
Since I somehow can’t resist complaining about absolute mana from heaven:
The only issue I see is this reliance on event sourcing — I get the reasoning but I much prefer regular state saving + audit log approaches.
Event sourcing seems like a complexity and performance liability — does anyone have any insight on the implementation/why I am wrong about my misgivings?
The amount of events in such system isn't going to be too crazy, unless it's some massive enterprise with thousands of principals, I would imagine...
It also seems cockroachdb first, but I'm glad i can use postgres. One fewer database to deploy and manage, and for my use case (basically myself and occasional friends and family) that's perfectly fine.
> The amount of events in such system isn't going to be too crazy, unless it's some massive enterprise with thousands of principals, I would imagine...
Right, but it's like... why take that liability in the first place when you have a rock solid and extensible DB like Postgres under the hood.
Why not take the CQRS (good idea), but not go as far as full-on Event Sourcing, and just make sure you keep an audit table log or even executed operation log?
IMO in practice almost on one actually goes back in time with Event Sourcing. Also there are so many things can bite you it just seems unnecessary.
I did some digging through the code, and I really wish they'd made a big DB interface and then made the event store an implementation of that. It looks like they did it the other way -- the default interface being the event store, and PG/CockroachDB being the underlying. It's a subtle difference but means a huge deal for actual swappability of backends.
I have to say, the code is also REALLY confusingly laid out. I just want to find the grpc/http handler that does like "create a user". I've been searching and clicking around for 10s of minutes -- maybe I don't read enough go.
> It also seems cockroachdb first, but I'm glad i can use postgres. One fewer database to deploy and manage, and for my use case (basically myself and occasional friends and family) that's perfectly fine.
I think of cockroachdb as basically postgres-with-stuff-bolted-on (albeit very good stuff, cockroach seems awesome), so I still consider it postgres-first! :)
Is there solid documentation or tutorial on deploying hydra + kratos? That's what stopped me last year. I've found some subtle pointers in some buried github issues, but nothing definitive. Which surprised me because one would thought that's the main use-case for many people and should be documented well.
I guess with Zitadel they don't paywall any features, and with self-hosted option you get essentially the same thing as with hosted. I think you can probably even do multi-instance, however maybe without a management interface for that part of it... When I read Ory language, it says to me "you can try it out locally and itegrate, but we want you in our hosted solution right after" (I could be wrong, I was just glancing casually...)
I don't think authelia has a UI, and it also has a mode where it integrates a bit more deeply with the routing mesh, to protect apps that do not do auth themselves. Authentik I've not looked into. It also seems that they differentiate self-hosted options into free and paid with different features...
Zitadel could be amazing, but as far as I can tell they don’t allow using your own UI screens, and it’s not obvious to me how you’d build a multi tenant SSO feature. They have the concept of organizations, but it’s not obvious to me how you’d route a user to the right login.
You can enable Domain Discovery to route users to the correct organization. Or you send a reserved scope with the auth request to select the organization. Building an own Login UI will be available in a couple of weeks (https://github.com/zitadel/zitadel/issues/5015)
That's basically what it does. You can activate Domain Discovery and verify a Domain on an organization, with that zitadel routes users to the organization based on the suffix (ie. email domain)
Thanks for clarifying, I must have missed it in the docs. If you see this comment, I'm wondering if this discovery functionality will also be customizable when the custom UI screens feature gets added?
