Live data from Hacker News

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

github.com

11–20 of 134 posts

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

#11
post #4

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)

Have you had a look at Authentik? It might fit your needs.

I think I did and when I couldn't find useful installation details I gave up, I don't use docker or kubernetes, so if projects can't be bothered to make information available for a generic install, I immediately lose interest.

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

#12
post #8

Can someone explain which services this is supposed to be an IdP for? As far as I know, services need to have the OIDC service registered (ie I can't just auth with this to Google or whatever).

This did indeed work for Google (that's the only one I tried), but the details of how this works is best detailed in this post: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

The above post was also linked from the obligator project's GH readme

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

#13
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.

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

#14
post #4

Earlier quoted context omitted.

Have you had a look at Authentik? It might fit your needs.

I think I did and when I couldn't find useful installation details I gave up, I don't use docker or kubernetes, so if projects can't be bothered to make information available for a generic install, I immediately lose interest.

I do plenty of native installs, and I find Docker based instructions to be a pretty nice universal codex for how things work.

Docker entryscripts sometimes have significant magic baked in (alas), but quite often Docker is a distribution mechanism more than anything else. The Docker guides are - 9 times out of 10 - more than informative enough to show how to DIY in any other of the dozens if not hundreds of other system types you might have.

If you want to resist using the easy thing, I personally think it behooves you to not bounce so quick. You don't have to use it, and it's good nearly universal documentation as to how to operate the thing.

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

#15
post #8

Can someone explain which services this is supposed to be an IdP for? As far as I know, services need to have the OIDC service registered (ie I can't just auth with this to Google or whatever).

Not sure I'm reading your question correctly, but if you want to use obligator as an IdP for other apps/services, they don't need to be registered as long as they set the client_id properly. That's the "anonymous client" auth described. However, in the simplest case you would have to verify any email addresses by having a confirmation email sent. To make this more streamlined, obligator can also act as an OIDC client for upstream OIDC providers such as Google, GitHub, etc. Once obligator has used an upstream provider to verify an email address, that address is treated exactly as if obligator had verified it itself. In this case you are correct in that registration is required with each upstream provider.

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

#16
post #8

Can someone explain which services this is supposed to be an IdP for? As far as I know, services need to have the OIDC service registered (ie I can't just auth with this to Google or whatever).

The readme links to another blog which explains the use case in more detail, but this quote sums it up I think “In a world where everyone's own website is its own OAuth server, it's obviously not practical to have an app developer register API keys at each.”

So, I build some app for Wordpress sites and self-hosters want to use my app against their WP site that they also made into an IDP. Then we get the issue of the app needing to be (pre)registered with the IDP, and set client_id and client_secret in its config.

Okay. I get that. But why on earth are we assuming that a self-hoster who can setup her own IDP cannot also create this app registration herself, and add a client_id/secret to a configfile before starting my app?

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

#19
post #18

I am only familiar with authentik. When I look at the comparison table it's super inaccurate for authentik. FYI.

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.

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

#20

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.
Post reply on HN