Show HN: Obligator – An OpenID Connect server for self-hosters
github.com
github.com
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.
Maybe something like this: https://ultimatesecurity.pro/post/first-login-flow/
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
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
Lots of options that are useful, and pretty good UI for setting things up
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
SQLlite would be super nice, but we lack engineering capacity right now to get that done.
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.
I always think there was not yet the „gitlab“ effect in the identity space.
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).
If you're demoing using https://openidconnect.net for example, set your Client ID to https://openidconnect.net
Likewise, your ClientID should match the url of the website you are using this to connect with.
This was mentioned in the GitHub readme too but didn't click until trying the demo
I'm on mobile, so haven't really checked where we differ in details.
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...
Right away, a partial mitigation for current versions of Portier is to modify the `email_*.mustache` templates to remove the link. But a second piece of information Portier leaks is simply which sites you're logging into. That's right in the subject for Portier, and not something you can customize for current versions.
I think it's worthy to try and harden against this type of attack, but I'm worried the effect is limited. There's often nothing stopping someone from simply starting the login process / creating a new session, so an attacker just has to know where, and there are a bunch of ways to find out.
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.
Easy != Simple. Not everyone wants to play around with Dockerfiles, docker compose and what not. Sometimes a plain binary is preferred. I say this as someone who likes docker for certain use cases but docker is not my solution for everything.
Apt rules!
https://github.com/eriksjolund/podman-networking-docs https://github.com/eriksjolund/podman-nginx-socket-activatio... https://github.com/eriksjolund/socket-activate-httpd https://github.com/eriksjolund/mariadb-podman-socket-activat... https://github.com/PhracturedBlue/podman-socket-activated-se...
If I find the time, I can test and write up about this integration.
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...
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.
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
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".
Account data. Usernames, emails, pictures, group memberships, roles. User data.
The above post was also linked from the obligator project's GH readme
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.
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.
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-...
I was so sad to see it die.
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?
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.
As for Forward Auth, the concept can be a bit fuzzy, and from what I gather, ZITADEL doesn't really support that.
Trusted Header Auth might work in some scenarios, but that definition is also a bit fuzzy, so hard to say for sure.
How would you accomplish the same thing using best practices? The closest is dynamic client registration without requiring an initial access token, but that still requires clients to support the protocol, and I know at least the Jellyfin and Discourse OIDC plugins do not. And even if they did what do you gain over anonymous auth?
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 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
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.
I believe you could setup email login by using the email TOTP 2FA much like I use my yubikey for passwordless authentication. You can modify the flows quite extensively... if you know what you are doing
Very well might’ve been, the mobile view of the table isn’t fantastic so it was quite a bit of scrolling; definitely could have messed that up.
> 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.
No, the user would need to enroll it. They could use a social login (upstream OIDC) without logging in through customizations, you can pre-create their user or create it on demand and give it appropriate access based on the upstream response. I don’t think you could implement magic links, even as customizable as it is.
"Passkeys" (FIDO2 Authenticators) support this. The CTAP2.1 protocol contains "enterprise attestation", which allows an Authenticator to identify itself uniquely to a particular Relying Party.
An explicit design goal of the FIDO standards is to prevent the server from knowing that two different FIDO credentials originated from the same Authenticator (in other words, treaing a new user as non-anonymous). In order to preserve that property, Authenticators need to be explicitly coded with the RPs for which they'll support Enterprise Attestation.
If you have such an authenticator, the server can say "give the owner of a passkey presenting a valid Enterprise Attestation for bob@example.com access to this account".
But, again, FIDO isn't supposed to let random web sites on the Internet notice that two "different" users are actually using the same passkey (tracking users between web sites!), so you can't get the property you're looking for without Enterprise Attestation.
That said, IndieAuth isn't OIDC and obligator may be the first OIDC implementation that uses these concepts.
[0]: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
* there are a huge number of middlemen in emailing that you have to trust. the sending email provider, the receiving email provider, ISP, email client, the device the client resides on. and everyone else in between. * unless you're just hosting an email server on your local network, starting up an email server that can successfully get its messages across the internet to your intended recipient is an extremely high barrier.
email is an extremely error-prone protocol. there's lots of reasons that government/health organizations don't send you personal private information by email and instead send you an email that says to come log into their secure platform to view the private information.
also, email has a potential for a big delay. a lot of times people need to log in quickly. email doesn't always reach the destination in a timely manner.
I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes.
So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over.
As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam.
The main problem is that it's not federated and completely under Facebook's control. Also, identity based on WhatsApp is still vulnerable to simjacking, correct?
Yes to both
I know the Authelia team is hard at working supporting some of the use cases that are currently not supported, so I will probably wait until some things are implemented there instead of switching.
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/
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.
Additionally, you’re conflating an OIDC server with a full IdP, which Hydra explicitly is not. I don’t need a full identity provider with support for user profile pictures and a pretty UI if all I’m doing is controlling access to API endpoints via OAuth2 client credentials. I already have an identity provider, and I’m not foolish enough to think that I should host one myself.
You’re completely correct in that you are not the intended demographic if you don’t understand the utility of the Ory stack, and that’s okay.
I think I understand the utilty of the Ory stack. Looks like some excellent kit doing excellent work for a lot of people. But it didn't solve my problems.
Hilarious.
Look, security UI is hard. Like, stumps experts hard. Like, they've been working at it for decades, trying to educate the population, hard.
I appreciate the will and the effort (as someone looking for their goldilocks OIDC proxy,) but this claim is a bit strong.
Love to see it