Live data from Hacker News

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

github.com

21–30 of 134 posts

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

#21
post #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…

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

Excellent question, and it gets into the meat of why I made this in the first place. obligator is the first piece of the puzzle I'm trying to solve to make self-hosting as easy and secure as running an app on your phone. In that world users cannot be expected to pre-register OAuth2 applications. But above and beyond that, registration creates friction that I feel is unnecessary and doesn't add enough additional security (and as mentioned can even reduce security when implemented poorly) for me to want to bother with it myself, so I built a server that doesn't require it.

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

#22

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 LLDAP for a super simple LDAP backend with SQL behind? That or kanidm if you want OIDC built in.

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

#23
post #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…

I don't remember the OIDC flows very well, but basically my question was whether I can use Obligator as an OIDC provider and Google as the client.

Ie can I log in to Google with Obligator? Or do I need to set up each client beforehand?

I skimmed the related article but didn't get it entirely, I'll need to read it more thoroughly.

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

#24
post #23
post #15

Earlier quoted context omitted.

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…

I don't remember the OIDC flows very well, but basically my question was whether I can use Obligator as an OIDC provider and Google as the client. Ie can I log in to Google with Obligator? Or do I need to set up each client beforehand? I skimmed the related article but didn't get it entirely, I'll need to read it more thoroughly.

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. You could also imagine browsers filling this in automatically. This didn't pan out in practice, primarily because no one used it[0].

However, it's becoming more realistic to run your own IdP, both by self-hosting and by using services such as Okta.

Tailscale actually let's you bring your own OIDC IdP. It uses WebFinger to prove an IdP has authority over a specific identity (email address). This is even more streamlined than entering your IdP directly. You just give Tailscale your email and they automatically send your to your IdP to authenticate.

But I wouldn't hold your breath for the major email providers to implement WebFinger so users can choose their own IdP. Which is one of many reasons I'm a big advocate of people using their own domain for email, even if the email itself is hosted by someone else (I use and love Fastmail).

[0]: https://meta.stackexchange.com/questions/307647/support-for-...

[1]: https://tailscale.com/kb/1240/sso-custom-oidc/

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

#25
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

IndieAuth is super super cool and a vital component to get back control of the internet to users, but I can't shake up the security concerns.

Also, near the end of the article. Using a security nightmare such as Wordpress as your identity provider, what could go wrong? It only takes one single rogue plugin.

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

#27

Earlier quoted context omitted.

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 syst…

It means I have to sit and read through the Dockerfile (or compose, in many cases, which is even worse) and figure out what its doing and what magic variables I need to provide etc, when just providing a binary download url and an example (or reference) config does just fine, not everyone uses docker

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

#28
post #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.

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. https://goauthentik.io/integrations/sources

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

#29
post #24
post #23

Earlier quoted context omitted.

I don't remember the OIDC flows very well, but basically my question was whether I can use Obligator as an OIDC provider and Google as the client. Ie can I log in to Google with Obligator? Or do I need to set up each client beforehand? I skimmed the related article but didn't get it entirely, I'll need to read it more thoroughly.

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.

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

#30
post #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.

I think I looked at the wrong column on mobile. While we're here though. Authentik has basic multitenancy support. I wonder if that qualifies as multi domain auth. Sorry about the mistake by the way.
Post reply on HN