Keycloak SSO with Docker Compose and Nginx

Original Article ↗ Hacker News Discussion ↗

Self‑hosted single sign-on with Keycloak provokes strong opinions: many value its rich feature set and standards support, but describe it as heavyweight, complex to configure, and quirky to run at scale or behind modern reverse proxies. Commenters trade deployment tips (Docker Compose, Nginx/Apache/Caddy, Terraform, realm export/import) and often offload complexity to the proxy layer or separate authorization services, while warning about performance limits and operational pitfalls such as clustering and realm count. A wide range of alternatives—Authelia, authentik, Zitadel, Dex, FusionAuth, Caddy plugins, and lighter OIDC servers—are compared on ease of setup, resource footprint, multi-factor support, openness of code, and suitability for homelab versus enterprise use.

Keycloak: power vs complexity

  • Widely viewed as powerful and feature‑rich (OIDC/SAML, realms/tenants, authorization services/UMA2), but also large, opinionated, and hard to learn.
  • Complaints include: confusing UI/docs, cumbersome admin APIs, partial/awkward export of configuration, statefulness making rebuilds tricky, and difficult clustering (multicast/UDP discovery, sticky sessions).
  • Some report good performance with the “optimized” Quarkus image (fast startup, modest RAM); others see slow starts and high resource use. Container size and recommended resources feel heavy for simple home or small setups.
  • Realms are promoted as multi‑tenant mechanism, but there are reports of serious slowdowns and breakage around a few hundred realms; this is described as a known long‑standing issue.

Reverse proxy and deployment patterns

  • Common pattern: terminate OIDC at a reverse proxy (Apache mod_auth_openidc, Nginx, Caddy, Traefik) and forward identity via headers to apps, avoiding per‑app OIDC complexity.
  • Some run Keycloak locally over HTTP and expose it via Cloudflare tunnels or auto‑TLS proxies (Caddy, Caddy‑Docker‑Proxy) to avoid manual certificate management; others prefer Nginx on the host for its maturity and documentation.
  • Keycloak can behave oddly behind proxies; extra proxy configuration has been needed in some setups. Local‑dev DNS mismatches (container hostname vs localhost) are a recurring annoyance.

Alternative identity/SSO solutions

  • Authelia: praised for very small footprint, simple file/env configuration, and strong proxy‑layer SSO for homelabs; lacks a full user‑admin UI. Concerns about infrequent releases; maintainers state it’s actively developed with a major pre‑release pending.
  • Authentik: appreciated for ease of setup and good docs, but criticized for a subdomain redirect bug and a non‑standard client‑credentials implementation; maintainers acknowledge and are shipping fixes.
  • Zitadel: repeatedly cited as much easier than Keycloak, with all MFA/passkey features in the open‑source version; requires its own DB (Postgres).
  • Others mentioned: Dex + oauth2‑proxy (simple federated IdP + forward auth), FusionAuth (closed‑source but free tier, Terraform‑friendly), JetBrains Hub, obligator (code‑driven, DB‑less but young), Teleport, lldap as lightweight LDAP.

Configuration, authorization, and security

  • Several users move authorization (groups/roles/permissions) out of Keycloak into app databases or dedicated authorization services, keeping Keycloak only for identity.
  • Infrastructure‑as‑code (e.g., Terraform providers) is used to avoid manual Keycloak configuration and drift.
  • Debate over security posture: Keycloak’s CVEs worry some, others argue transparent reporting is better than silently unknown flaws; closed‑source IdPs without CVEs are seen as no guarantee of safety.