Keycloak SSO with Docker Compose and Nginx

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • authelia

    The Single Sign-On Multi-Factor portal for web apps

  • > My only concern is that Authelia hasn't had a new release for more than a year, which raises security concerns.

    I'm a bit concerned about that too. When setting it up, I found a lot of their docs on github mentioned they have `template` and `expand-env` "configuration filters", then it took me entirely too long to realize that while the 4.38 pre-release notes, posted in January 2023, say it's "just around the corner", it's still being worked on.

    Having said that, there still seems to be somewhat active development. It may just be one person at this point.

    https://hub.docker.com/layers/authelia/authelia/v4.38.0-beta...

    https://github.com/authelia/authelia/commits/v4.38.0-beta3/

  • authentik

    The authentication glue you need.

  • For anyone, considering authentik, I want to warn you by saying "here be dragons."

    To start, I have protected 10+ services at any given time. Both in docker and k8s. Unless you enjoy configuring protection for each service independently, you'll have a bad time in authentik.

    Authentik suffers from a debilitating bug[0] where when using a single config to protect all services on subdomains (i.e. app1.example.com, app2.example.com, etc.) your users will be randomly redirected to a different service when reauthenticating after the session expires.

    [0]: https://github.com/goauthentik/authentik/issues/6886

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • obligator

    Simple and opinionated OpenID Connect server designed for self-hosters

  • I made a (incomplete) comparison table of various self-hostable OpenID Connect servers[0].

    One of the surprising things to me is just how massive the Keycloak codebase is.

    [0]: https://github.com/lastlogin-io/obligator?tab=readme-ov-file...

  • lldap

    Light LDAP implementation

  • I have Authelia running for 2+ years already. I configured it with LDAP using "LLDAP" [0], a lightweight LDAP implementation. I then use Caddy as a reverse proxy and integrate it [1] with Authelia. This works great. I have solid 2FA for all my services and I feel my self-hosted applications are secure enough to be accessed without VPN. My only concern is that Authelia hasn't had a new release for more than a year, which raises security concerns.

    [0] https://github.com/lldap/lldap

    [1] https://www.authelia.com/integration/proxies/caddy/

  • OpenID

    OpenID Certified™ OpenID Connect Relying Party implementation for Apache HTTP Server 2.x

  • I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_openidc

    In other words, I can protect arbitrary applications through my reverse proxy and require either certain claims/roles, or simplify auth to the point where my downstream app/API will just receive a bunch of headers like OIDC_CLAIM_sub, OIDC_CLAIM_name, OIDC_CLAIM_email through the internal network, not making me bother with configuring OIDC libraries for all of my APIs and configure them in each stack that I might use, but rather contain all of that complexity in the web server.

    Basically:

      user <==> Apache (with mod_auth_openidc) <==> API (with OIDC_ headers, if logged in)

  • caddy-docker-proxy

    Caddy as a reverse proxy for Docker

  • My go to is always this instead:

    https://github.com/lucaslorentz/caddy-docker-proxy

    Single label to a docker container and with correct DNS you’ll have an automatically managed certificate right away.

  • dex

    OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectors

  • Recently I looked into having a relatively simple SSO setup for my homelab. My main objective is that I could easily login with Google or GitHub auth. At my previous job I used both JetBrains Hub [1] and Keycloak but I found both of them a bit of a PITA to setup.

    JetBrains Hub was really, really easy to get going. As was my previous experience with them. The only thing that annoyed me was the lack of a latest tag on their Docker registry. Don't get me wrong, pinned versions are great, but for my personal use I mostly just want to update all my Docker containers in one go.

    On the other hand I found Keycloak very cumbersome to get going. It was pretty easy in dev mode, but I stumbled to get it going in production. AFAIK it had something to do with the wildcard Let's Encrypt cert that I tried to use. But after a couple of hours, I just gave up.

    I finally went with Dex [2]. I had previously put it off because of the lack of documentation, but in the end it was extremely easy to setup. It just required some basic YAML, a SQLite database and a (sub)domain. I combined Dex with the excellent OAuth2 Proxy and a custom Nginx (Proxy Manager) template for an easy two line SSO configuration on all of my internal services.

    In addition to this setup, I also added Cloudflare Access and WAF outside of my home to add some security. I only want to add some CrowdSec to get a little more insights.

    1. https://www.jetbrains.com/hub/

    2. https://dexidp.io/

    3. https://github.com/oauth2-proxy/oauth2-proxy

    3. https://github.com/alex3305/unraid-docker-templates

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • oauth2-proxy

    A reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.

  • Recently I looked into having a relatively simple SSO setup for my homelab. My main objective is that I could easily login with Google or GitHub auth. At my previous job I used both JetBrains Hub [1] and Keycloak but I found both of them a bit of a PITA to setup.

    JetBrains Hub was really, really easy to get going. As was my previous experience with them. The only thing that annoyed me was the lack of a latest tag on their Docker registry. Don't get me wrong, pinned versions are great, but for my personal use I mostly just want to update all my Docker containers in one go.

    On the other hand I found Keycloak very cumbersome to get going. It was pretty easy in dev mode, but I stumbled to get it going in production. AFAIK it had something to do with the wildcard Let's Encrypt cert that I tried to use. But after a couple of hours, I just gave up.

    I finally went with Dex [2]. I had previously put it off because of the lack of documentation, but in the end it was extremely easy to setup. It just required some basic YAML, a SQLite database and a (sub)domain. I combined Dex with the excellent OAuth2 Proxy and a custom Nginx (Proxy Manager) template for an easy two line SSO configuration on all of my internal services.

    In addition to this setup, I also added Cloudflare Access and WAF outside of my home to add some security. I only want to add some CrowdSec to get a little more insights.

    1. https://www.jetbrains.com/hub/

    2. https://dexidp.io/

    3. https://github.com/oauth2-proxy/oauth2-proxy

    3. https://github.com/alex3305/unraid-docker-templates

  • Recently I looked into having a relatively simple SSO setup for my homelab. My main objective is that I could easily login with Google or GitHub auth. At my previous job I used both JetBrains Hub [1] and Keycloak but I found both of them a bit of a PITA to setup.

    JetBrains Hub was really, really easy to get going. As was my previous experience with them. The only thing that annoyed me was the lack of a latest tag on their Docker registry. Don't get me wrong, pinned versions are great, but for my personal use I mostly just want to update all my Docker containers in one go.

    On the other hand I found Keycloak very cumbersome to get going. It was pretty easy in dev mode, but I stumbled to get it going in production. AFAIK it had something to do with the wildcard Let's Encrypt cert that I tried to use. But after a couple of hours, I just gave up.

    I finally went with Dex [2]. I had previously put it off because of the lack of documentation, but in the end it was extremely easy to setup. It just required some basic YAML, a SQLite database and a (sub)domain. I combined Dex with the excellent OAuth2 Proxy and a custom Nginx (Proxy Manager) template for an easy two line SSO configuration on all of my internal services.

    In addition to this setup, I also added Cloudflare Access and WAF outside of my home to add some security. I only want to add some CrowdSec to get a little more insights.

    1. https://www.jetbrains.com/hub/

    2. https://dexidp.io/

    3. https://github.com/oauth2-proxy/oauth2-proxy

    3. https://github.com/alex3305/unraid-docker-templates

  • You'd have FusionAuth issue the tokens through an authentication event (typically the authorization code grant for interactive sessions). Lots of flows with sequence diagrams outlined here [0].

    Then store the tokens on the client. For browsers dealing with first party apps (everything under the same domain) we recommend cookie storage of these tokens [1].

    Then have Caddy examine the tokens provided by the browser. Here's an example Caddy config I put together for a workshop [2].

    Finally, depending on your security posture, you might want to verify tokens both in app and at the proxy.

    0: https://fusionauth.io/articles/login-authentication-workflow...

    1: https://fusionauth.io/articles/oauth/oauth-token-storage

    2: https://github.com/FusionAuth/fusionauth-example-php-api-wor...

  • You'd have FusionAuth issue the tokens through an authentication event (typically the authorization code grant for interactive sessions). Lots of flows with sequence diagrams outlined here [0].

    Then store the tokens on the client. For browsers dealing with first party apps (everything under the same domain) we recommend cookie storage of these tokens [1].

    Then have Caddy examine the tokens provided by the browser. Here's an example Caddy config I put together for a workshop [2].

    Finally, depending on your security posture, you might want to verify tokens both in app and at the proxy.

    0: https://fusionauth.io/articles/login-authentication-workflow...

    1: https://fusionauth.io/articles/oauth/oauth-token-storage

    2: https://github.com/FusionAuth/fusionauth-example-php-api-wor...

  • fusionauth-issues

    FusionAuth issue submission project

  • Great question. Appreciate the interest.

    I can only speak from my perspective as an employee, not the whole company. It is something I've thought about. I will also ask the CEO/founder or other leaders to weigh in.

    Many devs care about open source when they are evaluating a solution, but many really want "free as in beer". They want to try a product without getting out the credit card or engaging with sales. We cater to the latter category, which wants to understand the product quality without talking to any sales people.

    Some of these folks use our community product for their production needs, which is perfectly fine. We have people running FusionAuth in production with 1000s of tenants or 10000+ applications. (I always say they "pay" us by filing bug reports, giving feedback and voting on feature requests.)

    But some decide they want to pay us for hosting, support or advanced features. Those choices help us build a business.

    Devs, and especially buyers, are interested in sustainability of a product they are going to integrate into their system. An auth provider isn't a javascript widget that you can easily drop in or remove from your system. It embeds in your system, even if you stick to a standard like OIDC, and is difficult to switch from, especially at scale. You want to be sure the company and product is going to stick around. (If you want to make sure you can run the product even if everyone at FusionAuth wins the lottery, we do offer source code escrow for a price, but haven't had anyone take us up on it.)

    FusionAuth is a profitable company (we did recently raise a round to accelerate growth, you can read more about that here [0]). Open source companies often have a hard time meeting the profit goals of the market or investors. This is a known issue and often results in relicensing or changing the rules, as we've seen with Hashicorp[1] and Elastic[2]. This switcheroo can cause issues, confusion, and ill-will; FusionAuth's licensing avoids that.

    FusionAuth also develops in the open[3]. This open development process gives us another common benefit people get from OSS--community feedback.

    Also, I don't want to throw shade at Ory and Zitadel, since I have no idea about their finances (apart from a brief look at Crunchbase, which shows they've raised 22.5M[4] and 2.5M[5] respectively). I hope they're building sustainable businesses, but selling closed source software is a sure route to a profitable business that has built many big companies (including in the auth space, such as Okta or Auth0). Again, this is not FUD (or at least I don't intend it to be!), just an honest assessment at the difficulties of making money in open source dev tools [6].

    We also compete on features, support and documentation. Again, I can't speak to Ory or Zitadel; they look nice, but I haven't built anything with them, so it is hard for me to know how good they are. I do know that we have had many clients appreciate of those aspects of our product.

    To sum up:

    * FusionAuth has a free option, which helps reduce friction and gives some of the benefits of OSS. The open process and escrow also give some of the benefits of OSS.

    * Some devs and buyers care about business sustainability, especially when integrating a tool deeply into their application. FusionAuth will never have to worry about relicensing a version because AWS is eating our SaaS revenue stream, for example.

    * We offer great support, documentation and intricate auth features at a reasonable price.

    Hope this helps.

    0: https://fusionauth.io/blog/fusionauth-and-updata

    1: https://www.hashicorp.com/license-faq

    2: https://www.elastic.co/pricing/faq/licensing

    3: https://github.com/FusionAuth/fusionauth-issues/issues/

    4: https://www.crunchbase.com/organization/ory/company_overview...

    5: https://www.crunchbase.com/organization/zitadel

    6: I wrote about this a few years ago on my personal blog: https://www.mooreds.com/wordpress/archives/3438

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts