Hacker News new | past | comments | ask | show | jobs | submit login

This looks like exactly what I was looking for.

I was looking for turnkey AuthN/AuthZ using OIDC for closed networks and self hosting, turnkey as in being able to drop a configured container in place and hit the ground running, and not being dex with keycloak.




If you're looking for something but more production ready, Authelia seems like a good option. Vouch and oauth2-proxy are even simpler but more specific in what they do. If you can provide more details of what you're trying to accomplish I might be able to give more specific advice.


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.


I've found https://zitadel.com/ to be a light weight version of keycloak.

Lots of options that are useful, and pretty good UI for setting things up


ZITADEL Co-Founder here.

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


The race really does seem to be between ZITADEL and Ory for the next generation of OIDC servers. Any chance of sqlite support in the future?


I think both products could even coexist ;-)

SQLlite would be super nice, but we lack engineering capacity right now to get that done.


> I think both products could even coexist

Fair enough, but developers and sysadmins don't want to choose between two great options. They want one obvious best option and a second option that is good enough and can be made better if option one turns evil.


Sure, there needs to be a „de facto“ OSS player in the space. Let me tell you that is what we definitely aspire to become.

I always think there was not yet the „gitlab“ effect in the identity space.


Gitlab is a great example of what I'm saying. Few use it today but that's probably where we would all go. You know, because we never actually learn the lessons of centralization.


Thanks for the recommendation. At a 30 second glance this looks the most promising so far!


How about KeyCloak? We use it for OIDC and it's feature rich with support for private key signing and back channel logout.

https://www.keycloak.org/docs/latest/securing_apps/


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?

https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec...

Keycloak ed25519 issue https://github.com/keycloak/keycloak/issues/15714


> 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?

By default Zitadel uses opaque tokens but you can switch to JWT and use an piece of JS code (actions) to insert whatever claim you want into the tokens


Go or better performance so...C# or Java? :)


troll much?


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.


I always assumed you had to create/manage user credentials inside KeyCloak. I'll take a deeper look at the docs.


You can modify the login flow in Keycloak to make it more or less just pass through the credentials/claims, but that's not the default.

Maybe something like this: https://ultimatesecurity.pro/post/first-login-flow/


Maybe Authentik can do what you need? It supports all the various protocols as provider and consumer.


I'll check it out, thanks for the recommendation.


You might want to take a look at FusionAuth (I'm an employee).

It's not open source, which may be a deal breaker for some, but it is "free as in beer". If you use the community edition and run it yourself, it is free for however many users you want. Also supports SAML (I know, I know, but when you need it you need it).

https://fusionauth.io/download




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: