9 ms·

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

273 points by apitman 3y ago

deleted 3y ago
[deleted]
throwaway67743 3y ago
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)
- bo0tzz 3y ago
  Have you had a look at Authentik? It might fit your needs.
  - throwaway67743 3y ago
    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.
    - jauntywundrkind 3y ago
      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.
      - throwaway67743 3y ago
        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
      - codegeek 3y ago
        "using the easy 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.
      - BodyCulture 3y ago
        apt install more easy and with auto updates safe! Docker too complicated, networking, security, dependencies, all messy after all these years. Apt rules!
        throwaway67743 3y ago
        Podman makes this better, as it doesn't trash my ipt/nft rules in the process, and its essentially stateless amongst other useful things
        apitman 3y ago
        How's the network performance on podman? It defaults to slirp4netns right?
        throwaway67743 3y ago
        Probably for user containers, but I've only ran it as root generally to avoid those sorts of limitations so haven't noticed any issues - I rarely use docker and only use for quick testing and then switch to non-docker installs
        3y ago
- XorNot 3y ago
  What's wrong with glauth? I forked it so I could build in the /etc/passwd support and it's been working great.
  - grepfru_it 3y ago
    Like raw /etc/passwd support or passwd support via PAM? Should always use PAM over reading passwd/shadow directly
  - throwaway67743 3y ago
    I stand corrected, looks like its come a long way since I last checked - will have to give it another go
- nitnelave 3y ago
  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.
  - throwaway67743 3y ago
    I hadn't seen that, thanks! even has clear information on how to build natively and has a reference config
- rescbr 3y ago
  I’ve found running Samba as a Domain Controller pretty straightforward for this exact use case.
  - BodyCulture 3y ago
    As userdb for keycloak? Please write about it!
    - rescbr 3y ago
      Haven't tried specifically with keycloak, but it should work. Keycloak advertises LDAP and MS Active Directory compatibility. If I find the time, I can test and write up about this integration.
kekub 3y ago
Amazing. I was looking for something like this about a year ago. Looks very promising and may be a good drop in replacement for some simple Auth0 use-cases as well as homelab setups. I was not able to get past „ redirect_uri must be on the same domain as client_id“. Maybe you can give an example of a valid client id for your demo instance.
- jackson1442 3y ago
  According to the Readme, the client ID should be the domain of the client. So some site https://access.site.com https://access.site.com would have the client ID https://access.site.com https://access.site.com
- camsjams 3y ago
  I too found this hard to reason, but figured it out: If you're demoing using https://openidconnect.net https://openidconnect.net for example, set your Client ID to https://openidconnect.net 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
- apitman 3y ago
  Sorry, this is indeed not very clear. Others already answered well, but if you look at the example[0] config you can see how you would use your own instance of obligator as a client to the instance running at lastlogin.io. This is a bit meta, but applies equally to any client application. [0]: https://github.com/anderspitman/obligator#running-it https://github.com/anderspitman/obligator#running-it
stavros 3y ago
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).
- camsjams 3y ago
  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 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
  - omneity 3y ago
    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.
    - apitman 3y ago
      What security concerns specifically?
      - omneity 3y ago
        Someone breaking into a Wordpress install due to a plugin's 0-day for example, and then being able to log into all the accounts managed by that WP's openID server.
- apitman 3y ago
  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.
benkillin 3y ago
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.
- apitman 3y ago
  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.
  - TrickardRixx 3y ago
    I'm looking for something that can federate identity, i.e. allow login with the @company microsoft identity provider, or support a users table, and ideally allows linking them. I just want to properly authenticate for internal tooling.
    - snappysnap 3y ago
      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/ https://www.keycloak.org/docs/latest/securing_apps/
      - cchance 3y ago
        i think most people look at keycloak, and just feel overwhelmed, but that seems to be the case for OIDC in general, they always feel insanely heavy, something like this with a flatfile config and single file executable seems pretty amazing.
      - TrickardRixx 3y ago
        I always assumed you had to create/manage user credentials inside KeyCloak. I'll take a deeper look at the docs.
I_am_tiberius 3y ago
For node.js there is node-oidc-provider.
dizhn 3y ago
I am only familiar with authentik. When I look at the comparison table it's super inaccurate for authentik. FYI.
- apitman 3y ago
  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.
  - mynameisvlad 3y ago
    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 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 https://goauthentik.io/integrations/sources
    - apitman 3y ago
      > 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.
Lammy 3y ago
> opinionated Love to see it
- throwawaaarrgh 3y ago
  Hate to see it...
- deleted 3y ago
  [deleted]
KronisLV 3y ago
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-docker 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 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 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/ https://goauthentik.io/
- apitman 3y ago
  > 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-security-topics https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... are much more useful.
- deleted 3y ago
  [deleted]
Havoc 3y ago
Must admit I've treated all my selfhosting like an coconut: Hard shell on the perimeter (firewall & wireguard)...but inside the home net its all just wide open.
- deleted 3y ago
  [deleted]
salzig 3y ago
Reminds me of https://github.com/dexidp/dex https://github.com/dexidp/dex
- deleted 3y ago
  [deleted]
sisve 3y ago
I was expecting hydra / kratos to show up as an alternative.. but did not see any. Does any have any experience, good or bad about it? https://github.com/ory/kratos https://github.com/ory/kratos
- deleted 3y ago
  [deleted]
- apitman 3y ago
  Hydra is in the table, but you might have to scroll sideways to see it. That column also still needs to be filled out
  - hatf0 3y ago
    The comparison with simply just Hydra is rather unfair too as the strength with Ory products is when they work in tandem (e.g. oathkeeper & hydra). Hydra is as barebones as you can get for a OAuth2 provider - that’s all it does & is meant to do. Stack it with Oathkeeper and you have a dynamic way of enforcing endpoint authentication that can entirely be managed using Kubernetes custom resources. Nothing I’ve found comes even close to touching the Ory stack in that regard.
    - apitman 3y ago
      The Ory stack looks to be very high quality for sure. But so far in this thread there's been mentioned Hydra, Kratos, and Oathkeeper in order to run an OIDC server. You say Hydra is as barebones as you can get, but by itself it has 58 direct dependencies. I'm sorry, it just seems to be targeted at a completely different demographic.
      - hatf0 3y ago
        When has the number of dependencies ever directly correlated with the feature set of an application? Have you ever looked at a node_modules folder? More over, how is that relevant in any way? This argument against dependencies has always felt like weird NIH-ism spawned out of the same crowd who still thinks that C is a good programming language. Have fun reinventing the wheel, but I’ll take my dependencies to go. 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.
jupp0r 3y ago
Using email magic links as authentication mechanism is not a great choice in my opinion as email is not a very secure protocol if you think about the default smtp security guarantees and man-in-the-middle interception, either on the smtp or on the network level if servers communicate unencrypted.
- KRAKRISMOTT 3y ago
  If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.
  - apitman 3y ago
    This. As sad as it is, email is the defacto identity on the internet. Every system I'm aware of falls back on email and/or phone numbers for recovery.
    - v2223943777435 3y ago
      just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication. * 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.
      - apitman 3y ago
AceJohnny2 3y ago
> By forcing the user to decide whether they trust the actual domain where the ID token will be sent, and not displaying any sort of logo which can be faked, security is improved. 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.
- apitman 3y ago
  I agree the wording is too strong here. That said, did you read about the phishing exploit I linked in the readme?
- deleted 3y ago
  [deleted]
krantic 3y ago
I could recommend https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider supports most of the oidc/oauth 2 rabbit hole specs.
- deleted 3y ago
  [deleted]
- apitman 3y ago
  This looks really good. I'll see about adding it to the table.
moontear 3y ago
I was going to comment „but I can already do a lot of that with Authelia and it is very simple to configure“, but then I found your very good comparison page - good comparison! 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.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
BOOSTERHIDROGEN 3y ago
I'm using https://github.com/thomseddon/traefik-forward-auth https://github.com/thomseddon/traefik-forward-auth for my selfhosted ? is it better in term of security, thanks.
hkt 3y ago
Genius. Not having to register is brilliant and I love it. I'll be watching this project and using it.
- apitman 3y ago
  Just to be clear I was not the one to come up with anonymous client auth. This comes from the IndieAuth/IndieWeb community, and I link to Aaron Parecki's article[0] describing it in the repo. 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 https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
kosinus 3y ago
This looks like it has the same core functionality as Portier? https://github.com/portier/portier-broker https://github.com/portier/portier-broker I'm on mobile, so haven't really checked where we differ in details.
- apitman 3y ago
  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-Goals.md https://github.com/portier/portier.github.io/blob/main/Non-G...
  - kosinus 3y ago
    Thanks for pointing that out! Maybe we can improve on that, even if we keep it as a non-goal. 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.
Wronnay 3y ago
Cool, but I looks like the creator didn't really look deep in the competition. Many of the question marks in the comparison table can be replaced by a checkmark.
- langur 3y ago
  Indeed. It is slightly misleading at first glance. But the author has stated that it is incomplete. ZITADEL(https://zitadel.com/ https://zitadel.com/), for example, pretty much checks almost all the boxes.
  - BodyCulture 3y ago
    Which not? Thank you!
    - langur 3y ago
      ZITADEL doesn't support anonymous clients. Honestly, it's not the best practice anyway. 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.
      - apitman 3y ago
        > ZITADEL doesn't support anonymous clients. Honestly, it's not the best practice anyway. 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?
- apitman 3y ago
  I looked more closely at the simpler ones, since simplicity was a baseline requirement for me when I went looking for a server to meet my needs. If the docs for something were too complicated to even determine if it supported the features I need then I tended not to spend much time digging through them.
jinnko 3y ago
I recently came across Caddy Security[1], and while it's not an OIDC IdP itself, it does serve as a good authentication gateway that's easy to get up and running and maintain. 1: https://authp.github.io/ https://authp.github.io/
- __float 3y ago
  I've been using Caddy Security for personal use for a while now. I'd almost say it does too much, but you can turn almost everything off if you want.
lakomen 3y ago
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 https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
- apitman 3y ago
  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".
  - lakomen 3y ago
    What user data? User data... idk how else to put it. Account data. Usernames, emails, pictures, group memberships, roles. User data.
    - apitman 3y ago
      Right, I wasn't sure if you were referring specifically to the user's profile information on the OIDC server, the other user data stored by the same entity which runs the OIDC server (which is common but not the case for obligator because it's identity-only), or the user's data on the app that they're trying to log into.
mooreds 3y ago
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-1e2MOyuUqXIiPuj7rPfPrHAI/edit#gid=0 https://docs.google.com/spreadsheets/d/16Ya5KsmEpczTmoTk5J-1...
- apitman 3y ago
  > 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.

273 points by apitman 3y ago

deleted 3y ago

[deleted]

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)

bo0tzz 3y ago
Have you had a look at Authentik? It might fit your needs.
- throwaway67743 3y ago
  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.
  - jauntywundrkind 3y ago
    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.
    - throwaway67743 3y ago
      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
    - codegeek 3y ago
      "using the easy 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.
    - BodyCulture 3y ago
      apt install more easy and with auto updates safe! Docker too complicated, networking, security, dependencies, all messy after all these years. Apt rules!
      - throwaway67743 3y ago
        Podman makes this better, as it doesn't trash my ipt/nft rules in the process, and its essentially stateless amongst other useful things
        apitman 3y ago
        How's the network performance on podman? It defaults to slirp4netns right?
        throwaway67743 3y ago
        Probably for user containers, but I've only ran it as root generally to avoid those sorts of limitations so haven't noticed any issues - I rarely use docker and only use for quick testing and then switch to non-docker installs
        3y ago
XorNot 3y ago
What's wrong with glauth? I forked it so I could build in the /etc/passwd support and it's been working great.
- grepfru_it 3y ago
  Like raw /etc/passwd support or passwd support via PAM? Should always use PAM over reading passwd/shadow directly
- throwaway67743 3y ago
  I stand corrected, looks like its come a long way since I last checked - will have to give it another go
nitnelave 3y ago
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.
- throwaway67743 3y ago
  I hadn't seen that, thanks! even has clear information on how to build natively and has a reference config
rescbr 3y ago
I’ve found running Samba as a Domain Controller pretty straightforward for this exact use case.
- BodyCulture 3y ago
  As userdb for keycloak? Please write about it!
  - rescbr 3y ago
    Haven't tried specifically with keycloak, but it should work. Keycloak advertises LDAP and MS Active Directory compatibility. If I find the time, I can test and write up about this integration.

kekub 3y ago

Amazing. I was looking for something like this about a year ago. Looks very promising and may be a good drop in replacement for some simple Auth0 use-cases as well as homelab setups. I was not able to get past „ redirect_uri must be on the same domain as client_id“. Maybe you can give an example of a valid client id for your demo instance.

jackson1442 3y ago
According to the Readme, the client ID should be the domain of the client. So some site https://access.site.com https://access.site.com would have the client ID https://access.site.com https://access.site.com
camsjams 3y ago
I too found this hard to reason, but figured it out: If you're demoing using https://openidconnect.net https://openidconnect.net for example, set your Client ID to https://openidconnect.net 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
apitman 3y ago
Sorry, this is indeed not very clear. Others already answered well, but if you look at the example[0] config you can see how you would use your own instance of obligator as a client to the instance running at lastlogin.io. This is a bit meta, but applies equally to any client application. [0]: https://github.com/anderspitman/obligator#running-it https://github.com/anderspitman/obligator#running-it

stavros 3y ago

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).

camsjams 3y ago
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 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
- omneity 3y ago
  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.
  - apitman 3y ago
    What security concerns specifically?
    - omneity 3y ago
      Someone breaking into a Wordpress install due to a plugin's 0-day for example, and then being able to log into all the accounts managed by that WP's openID server.
apitman 3y ago
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.

benkillin 3y ago

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.

apitman 3y ago
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.
- TrickardRixx 3y ago
  I'm looking for something that can federate identity, i.e. allow login with the @company microsoft identity provider, or support a users table, and ideally allows linking them. I just want to properly authenticate for internal tooling.
  - snappysnap 3y ago
    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/ https://www.keycloak.org/docs/latest/securing_apps/
    - cchance 3y ago
      i think most people look at keycloak, and just feel overwhelmed, but that seems to be the case for OIDC in general, they always feel insanely heavy, something like this with a flatfile config and single file executable seems pretty amazing.
    - TrickardRixx 3y ago
      I always assumed you had to create/manage user credentials inside KeyCloak. I'll take a deeper look at the docs.

I_am_tiberius 3y ago

For node.js there is node-oidc-provider.

dizhn 3y ago

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

apitman 3y ago
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.
- mynameisvlad 3y ago
  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 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 https://goauthentik.io/integrations/sources
  - apitman 3y ago
    > 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.

Lammy 3y ago

> opinionated Love to see it

throwawaaarrgh 3y ago
Hate to see it...
deleted 3y ago
[deleted]

KronisLV 3y ago

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

apitman 3y ago
> 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-security-topics https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... are much more useful.
deleted 3y ago
[deleted]

Havoc 3y ago

Must admit I've treated all my selfhosting like an coconut: Hard shell on the perimeter (firewall & wireguard)...but inside the home net its all just wide open.

deleted 3y ago
[deleted]

salzig 3y ago

Reminds me of https://github.com/dexidp/dex https://github.com/dexidp/dex

deleted 3y ago
[deleted]

sisve 3y ago

I was expecting hydra / kratos to show up as an alternative.. but did not see any. Does any have any experience, good or bad about it? https://github.com/ory/kratos https://github.com/ory/kratos

deleted 3y ago
[deleted]
apitman 3y ago
Hydra is in the table, but you might have to scroll sideways to see it. That column also still needs to be filled out
- hatf0 3y ago
  The comparison with simply just Hydra is rather unfair too as the strength with Ory products is when they work in tandem (e.g. oathkeeper & hydra). Hydra is as barebones as you can get for a OAuth2 provider - that’s all it does & is meant to do. Stack it with Oathkeeper and you have a dynamic way of enforcing endpoint authentication that can entirely be managed using Kubernetes custom resources. Nothing I’ve found comes even close to touching the Ory stack in that regard.
  - apitman 3y ago
    The Ory stack looks to be very high quality for sure. But so far in this thread there's been mentioned Hydra, Kratos, and Oathkeeper in order to run an OIDC server. You say Hydra is as barebones as you can get, but by itself it has 58 direct dependencies. I'm sorry, it just seems to be targeted at a completely different demographic.
    - hatf0 3y ago
      When has the number of dependencies ever directly correlated with the feature set of an application? Have you ever looked at a node_modules folder? More over, how is that relevant in any way? This argument against dependencies has always felt like weird NIH-ism spawned out of the same crowd who still thinks that C is a good programming language. Have fun reinventing the wheel, but I’ll take my dependencies to go. 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.

jupp0r 3y ago

Using email magic links as authentication mechanism is not a great choice in my opinion as email is not a very secure protocol if you think about the default smtp security guarantees and man-in-the-middle interception, either on the smtp or on the network level if servers communicate unencrypted.

KRAKRISMOTT 3y ago
If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.
- apitman 3y ago
  This. As sad as it is, email is the defacto identity on the internet. Every system I'm aware of falls back on email and/or phone numbers for recovery.
  - v2223943777435 3y ago
    just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication. * 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.
    - apitman 3y ago

AceJohnny2 3y ago

> By forcing the user to decide whether they trust the actual domain where the ID token will be sent, and not displaying any sort of logo which can be faked, security is improved. 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.

apitman 3y ago
I agree the wording is too strong here. That said, did you read about the phishing exploit I linked in the readme?
deleted 3y ago
[deleted]

krantic 3y ago

I could recommend https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider supports most of the oidc/oauth 2 rabbit hole specs.

deleted 3y ago
[deleted]
apitman 3y ago
This looks really good. I'll see about adding it to the table.

moontear 3y ago

I was going to comment „but I can already do a lot of that with Authelia and it is very simple to configure“, but then I found your very good comparison page - good comparison! 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.

deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

BOOSTERHIDROGEN 3y ago

I'm using https://github.com/thomseddon/traefik-forward-auth https://github.com/thomseddon/traefik-forward-auth for my selfhosted ? is it better in term of security, thanks.

hkt 3y ago

Genius. Not having to register is brilliant and I love it. I'll be watching this project and using it.

apitman 3y ago
Just to be clear I was not the one to come up with anonymous client auth. This comes from the IndieAuth/IndieWeb community, and I link to Aaron Parecki's article[0] describing it in the repo. 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 https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

kosinus 3y ago

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

apitman 3y ago
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-Goals.md https://github.com/portier/portier.github.io/blob/main/Non-G...
- kosinus 3y ago
  Thanks for pointing that out! Maybe we can improve on that, even if we keep it as a non-goal. 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.

Wronnay 3y ago

Cool, but I looks like the creator didn't really look deep in the competition. Many of the question marks in the comparison table can be replaced by a checkmark.

langur 3y ago
Indeed. It is slightly misleading at first glance. But the author has stated that it is incomplete. ZITADEL(https://zitadel.com/ https://zitadel.com/), for example, pretty much checks almost all the boxes.
- BodyCulture 3y ago
  Which not? Thank you!
  - langur 3y ago
    ZITADEL doesn't support anonymous clients. Honestly, it's not the best practice anyway. 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.
    - apitman 3y ago
      > ZITADEL doesn't support anonymous clients. Honestly, it's not the best practice anyway. 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?
apitman 3y ago
I looked more closely at the simpler ones, since simplicity was a baseline requirement for me when I went looking for a server to meet my needs. If the docs for something were too complicated to even determine if it supported the features I need then I tended not to spend much time digging through them.

jinnko 3y ago

I recently came across Caddy Security[1], and while it's not an OIDC IdP itself, it does serve as a good authentication gateway that's easy to get up and running and maintain. 1: https://authp.github.io/ https://authp.github.io/

__float 3y ago
I've been using Caddy Security for personal use for a while now. I'd almost say it does too much, but you can turn almost everything off if you want.

lakomen 3y ago

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 https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

apitman 3y ago
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".
- lakomen 3y ago
  What user data? User data... idk how else to put it. Account data. Usernames, emails, pictures, group memberships, roles. User data.
  - apitman 3y ago
    Right, I wasn't sure if you were referring specifically to the user's profile information on the OIDC server, the other user data stored by the same entity which runs the OIDC server (which is common but not the case for obligator because it's identity-only), or the user's data on the app that they're trying to log into.

mooreds 3y ago

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-1e2MOyuUqXIiPuj7rPfPrHAI/edit#gid=0 https://docs.google.com/spreadsheets/d/16Ya5KsmEpczTmoTk5J-1...

apitman 3y ago
> 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.