Live data from Hacker News

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

github.com

101–110 of 134 posts

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

#101

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.

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

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

#102
Disclosure, I'm an employee of FusionAuth, which is another auth server in this space.

Interesting that this project supports features you'd need for an internal network setup (trusted headers, forward auth) and an external facing network (support for Google/other identity providers, anonymous clients based on domain name).

I'd be careful mixing those two feature sets myself. Maybe I'm missing something.

I also loved the comparison of OSS identity providers[0]. Putting it into a google sheet for easy sharing and commenting is a great idea!

0: https://docs.google.com/spreadsheets/d/16Ya5KsmEpczTmoTk5J-1...

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

#103

Earlier quoted context omitted.

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

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

#104

Disclosure, I'm an employee of FusionAuth, which is another auth server in this space. Interesting that this project supports features you'd need for an internal network setup (trusted headers, forward auth) and an external facing network (support for Google/other identity providers, anonymous clients based on domain name). I'd be careful mixing those two feature sets myself. Maybe I'm missing something. I also loved…

> Interesting that this project supports features you'd need for an internal network setup (trusted headers, forward auth) and an external facing network (support for Google/other identity providers, anonymous clients based on domain name).

Yep. There are two primary schools of thought on self-hosting, with echos of the VPN vs BeyondCorps tradeoffs.

The VPN approach is to keep everything locked down on a private network, likely a virtual network using WireGuard, and likely provided by Tailscale. The main tradeoff here for self-hosting is that everyone you want to share with needs access to your network, and unless no one has any private data you're still going to need account management of some sort. Also if one of your trusted devices gets compromised, the attacker can get access to the "soft squishy" inside of your network. If you're doing single user instance (SUI) hosting, this is likely what you want.

The BeyondCorps approach raises security to the application level, and exposes services directly to the internet. The main tradeoff here is that each app represents a potential attack vector. Since I host websites and file servers, obligator was built to facilitate this use case.

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

#105

Question about this indie auth thing, or anonymous clients, mentioned at the linked page. Wouldn't that effectively grant access to your user data to everyone, regardless of their intentions? Meta, for instance, has very strict TOS and privacy policy checks before approving a client_id. And those checks are on-going. https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

What user data are you referring to?

One problem with comparing to social login providers is that their OAuth2 APIs tend to provide a lot more access than just OIDC, which greatly increases the risk of phishing and other attacks. Since a simple OIDC server like obligator only deals with identity, the worst case scenario of a phishing attack is that the user's email address is exposed to the attacker.

You can think of obligator as a server that responds to client app requests with a response of "I have verified that the user running this OIDC session has control of X email address as of Y time".

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

#106
post #97

Earlier quoted context omitted.

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

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?

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

#107
post #87

This looks like it has the same core functionality as Portier? https://github.com/portier/portier-broker I'm on mobile, so haven't really checked where we differ in details.

This looks great! I will definitely be taking a close look. Only thing I noticed with a quick try is that portier allows both a magic link and code for passwordless email login. Magic links are much more vulnerable to attack than codes because the email providers and anyone who may have access to your email can hijack your login from any location. I think it's fine to provide magic links but that choice should be the user's option when they enter their email, after warning them of the security implications.

EDIT: They actually address this in their non-goals document[0] but disagree with the decision, since many users may not realize the tradeoffs.

[0]: https://github.com/portier/portier.github.io/blob/main/Non-G...

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

#108
post #97

Earlier quoted context omitted.

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

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.

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

#109

Earlier quoted context omitted.

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…

apt install more easy and with auto updates safe! Docker too complicated, networking, security, dependencies, all messy after all these years. Apt rules!

Podman makes this better, as it doesn't trash my ipt/nft rules in the process, and its essentially stateless amongst other useful things

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

#110
post #99

Earlier quoted context omitted.

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…

Go or better performance so...C# or Java? :)
Post reply on HN