I'm looking for something that can federate identity, i.e. allow login with the @company microsoft identity provider, or support a users table, and ideally allows linking them. I just want to properly authenticate for internal tooling.
Thank you for the nice words you describe well what we try to achieve!
With ZITADEL we aspire to become the best of Auth0 and Keycloak in more modern package. Or in other words are a end-to-end open source identity infrastructure. I know this sounds a little unspecific but our goals are:
1) Have AuthN/AuthZ, Login, SSO as Turnkey features but also allow people to build their own UIs
2) Have an audit trail that allows people to see all changes ever made
3) Give devs the ability to extend zitadel with custom code (actions)
4) Support well given standards (OIDC/Oauth/SAML/LDAP) with certification if possible
5) Be ease to operate and scale
6) Provide APIs for everything ;-)
Btw. its always nice to see other projects to solve problems in the identity space. To me it feels like Obligator can, at the moment, be best compared to Dex since it feels a lot like a façade service that has little user management capabilities (not that this is a bad thing) but wraps them for easier usage in multiple services. But please take this observation with a lot of salt since I have not used or tinkered with Obligator.
I use keycloak, but it's Java and I need Go or better performance.
With the new UI mass admin tasks are no longer possible.
At least version upgrades are better now.
Keycloak has no ed25519 support. Louketo proxy or whatever it's called nowadays only supports RS256, so I had to write my own OIDC middleware.
At least they stopped generating UUIDv4 secrets.
Hydra is too complex.
Dex is too simple.
Identity Server lacks performance because C#.
Zitadel, heard but not tried yet. The keycloak vs zitadel page doesn't help. Is the Zitadel access token also jwt like in keycloak and included role membership?
I use a Vue client specifically for Keycloak.
The generic openid-connect-client is unmaintained.
The TS fork doesn't have a working, maintained, reactive implementation.
Why does OIDC have to be so complicated?
I know why... so you, like with k8s, trust external, paid for (expensively), companies with your work and data.
The old "make it complicated so people would rather pay for our services".
Remember the story about the oauth1 creator quitting the oauth2 project?
i think most people look at keycloak, and just feel overwhelmed, but that seems to be the case for OIDC in general, they always feel insanely heavy, something like this with a flatfile config and single file executable seems pretty amazing.
bennyp101|2 years ago
Lots of options that are useful, and pretty good UI for setting things up
ffo|2 years ago
Thank you for the nice words you describe well what we try to achieve!
With ZITADEL we aspire to become the best of Auth0 and Keycloak in more modern package. Or in other words are a end-to-end open source identity infrastructure. I know this sounds a little unspecific but our goals are:
1) Have AuthN/AuthZ, Login, SSO as Turnkey features but also allow people to build their own UIs
2) Have an audit trail that allows people to see all changes ever made
3) Give devs the ability to extend zitadel with custom code (actions)
4) Support well given standards (OIDC/Oauth/SAML/LDAP) with certification if possible
5) Be ease to operate and scale
6) Provide APIs for everything ;-)
Btw. its always nice to see other projects to solve problems in the identity space. To me it feels like Obligator can, at the moment, be best compared to Dex since it feels a lot like a façade service that has little user management capabilities (not that this is a bad thing) but wraps them for easier usage in multiple services. But please take this observation with a lot of salt since I have not used or tinkered with Obligator.
Cheers Florian
TrickardRixx|2 years ago
snappysnap|2 years ago
https://www.keycloak.org/docs/latest/securing_apps/
lakomen|2 years ago
With the new UI mass admin tasks are no longer possible. At least version upgrades are better now.
Keycloak has no ed25519 support. Louketo proxy or whatever it's called nowadays only supports RS256, so I had to write my own OIDC middleware. At least they stopped generating UUIDv4 secrets.
Hydra is too complex.
Dex is too simple.
Identity Server lacks performance because C#.
Zitadel, heard but not tried yet. The keycloak vs zitadel page doesn't help. Is the Zitadel access token also jwt like in keycloak and included role membership?
I use a Vue client specifically for Keycloak. The generic openid-connect-client is unmaintained. The TS fork doesn't have a working, maintained, reactive implementation.
Why does OIDC have to be so complicated? I know why... so you, like with k8s, trust external, paid for (expensively), companies with your work and data.
The old "make it complicated so people would rather pay for our services".
Remember the story about the oauth1 creator quitting the oauth2 project?
https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec...
Keycloak ed25519 issue https://github.com/keycloak/keycloak/issues/15714
cchance|2 years ago
TrickardRixx|2 years ago
RealStickman_|2 years ago
TrickardRixx|2 years ago