Live data from Hacker News

Show HN: Obligator – An OpenID Connect server for self-hosters

github.com

31–40 of 134 posts

Re: Show HN: Obligator – An OpenID Connect server for self-hosters

#31
Personally I went with Keycloak, because it's fairly well documented and also has Docker images available: https://www.keycloak.org/getting-started/getting-started-doc... although the fact that they want you to create an "optimized" image yourself and have a long setup process on startup otherwise is slightly annoying: https://www.keycloak.org/server/containers

Regardless, with something like mod_auth_openidc or another Relying Party implementation, all of the sudden authn/authz becomes easier to manage (you can literally get user information including roles in headers that are passed from your gateway/relying party to apps behind the reverse proxy), regardless of what you have actually running your APIs: https://github.com/OpenIDC/mod_auth_openidc (there are other options, of course, but I went with that because I already use mod_md).

It's actually cool that there are plentiful options in the space, since OIDC is pretty complex in of itself and attempts at creating something pleasant to actually use are always welcome, I've also heard good things about Authentik: https://goauthentik.io/

Re: Show HN: Obligator – An OpenID Connect server for self-hosters

#32
post #9

Ohh, looks extremely promising, I've been after something with a bit more flexibility than Dex while not being Keycloak/Java etc, an LDAP backend would be awesome as well though (another thing thats lacking is a simple ldap server, perhaps with sql as db, openldap is excessive and glauth isn't there)

What's wrong with glauth? I forked it so I could build in the /etc/passwd support and it's been working great.

I stand corrected, looks like its come a long way since I last checked - will have to give it another go

Re: Show HN: Obligator – An OpenID Connect server for self-hosters

#33
post #19

Earlier quoted context omitted.

Authentik is one of the ones I actually searched more closely through the docs, as it's a popular choice for self-hosting. Can you point out specific inaccuracies so I can fix them? It's tricky to figure out if some features are supported across different servers because the features have different names, and the more features a server has the harder it is to dig through.

Some I found: - I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out. https://goauthentik.io/docs/providers/proxy/custom_headers - It doesn’t offer “Passwordless email login”, but offers “passwordless login” in the form of passkeys (with a tiny bit of setup). - Definitely offers upstream OIDC, I have my instance set up to be able to sign in through AAD or locally. htt…

> I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out

Fixed, thanks. Do you know if custom headers are returned when using forward auth, or only when Authentik is acting as a proxy?

> It doesn’t offer “Passwordless email login”, but offers “passwordless login” in the form of passkeys (with a tiny bit of setup).

In the case of obligator, email support specifically is important. Passkeys are really cool, but unless I'm mistaken there's no way for me to say "give the owner of this passkey access to this data" even if they've never yet logged in to your system. This is a critical use case which works great with email, even having a built-in way to notify them of their new access. I would love to see passkeys extended with some sort of proof that the passkey is tied to a specific email address (or other global ID), so you can login without talking to an IdP but also get the benefits mentioned above.

> Definitely offers upstream OIDC, I have my instance set up to be able to sign in through AAD or locally

Already had that one. Were you maybe looking at Authelia? Though I believe I read somewhere that they are working on support too.

Re: Show HN: Obligator – An OpenID Connect server for self-hosters

#34

Personally I went with Keycloak, because it's fairly well documented and also has Docker images available: https://www.keycloak.org/getting-started/getting-started-doc... although the fact that they want you to create an "optimized" image yourself and have a long setup process on startup otherwise is slightly annoying: https://www.keycloak.org/server/containers Regardless, with something like mod_auth_openidc or anot…

> since OIDC is pretty complex in of itself

Obviously this is subjective, but I actually disagree somewhat. Once you get down to actually writing the code to implement OIDC, it's rather simple. But I feel like the specs make it look pretty scary.

I think the confusing part for me was understanding why some parts of it seemed to have so much song and dance (ie the three legged authorization code flow, PKCE, etc). I find the best way to understand the complexity is by having it explained in the context of what attacks are mitigated by specific steps. For that, documents like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... are much more useful.

Re: Show HN: Obligator – An OpenID Connect server for self-hosters

#35
post #29
post #24

Earlier quoted context omitted.

Ahh that makes sense. And you are essentially correct. Generally speaking clients expect to be aware of who their IdP is, and currently Google/Facebook/Apple/Microsoft have a stranglehold on the "approved login IdP", with a few dark horses like GitHub. The original vision of OpenID (ie pre-OpenID Connect) was for applications to support any IdP, and you just tell the app what your IdP is when you create your account.…

Thanks, this is very informative. I was really hoping OIDC+WebFinger would catch on, it was a more or less equivalent experience to Mozilla's Persona, which I was a big fan of.

Thank you for mentioning Persona. I sadly missed that train when it was a thing, but it's always sounded cool. I think it's basically what I want. Comparing to it in the docs would actually probably be a good way to explain the purpose of obligator.
Post reply on HN