Keycloak SSO con Docker Compose y Nginx

Artículo original ↗ Discusión en Hacker News ↗

El inicio de sesión único autohospedado con Keycloak provoca opiniones intensas: muchos valoran su amplio conjunto de funciones y el soporte de estándares, pero lo describen como pesado, complejo de configurar y peculiar de operar a escala o detrás de proxies inversos modernos. Los comentaristas comparten consejos de despliegue (Docker Compose, Nginx/Apache/Caddy, Terraform, exportación/importación de realms) y a menudo trasladan la complejidad a la capa de proxy o a servicios de autorización separados, a la vez que advierten sobre límites de rendimiento y problemas operativos como el clustering y el número de realms. Se compara una amplia gama de alternativas—Authelia, authentik, Zitadel, Dex, FusionAuth, plugins de Caddy y servidores OIDC más ligeros—según la facilidad de instalación, huella de recursos, soporte de multifactor, apertura del código y adecuación para homelab frente a uso empresarial.

Keycloak: potencia vs complejidad

  • Ampliamente considerado potente y con muchas funciones (OIDC/SAML, realms/tenants, servicios de autorización/UMA2), pero también grande, opinativo y difícil de aprender.
  • Las quejas incluyen: UI/docs confusas, APIs de administración engorrosas, exportación parcial o torpe de la configuración, estado persistente que complica las reconstrucciones y clustering difícil (descubrimiento multicast/UDP, sesiones persistentes).
  • Algunos informan buen rendimiento con la imagen Quarkus “optimizada” (arranque rápido, RAM modesta); otros ven arranques lentos y alto uso de recursos. El tamaño del contenedor y los recursos recomendados parecen pesados para configuraciones domésticas o pequeñas.
  • Los realms se promocionan como mecanismo multiusuario, pero hay informes de ralentizaciones graves y fallos alrededor de unos cientos de realms; esto se describe como un problema conocido de larga data.

Patrones de proxy inverso y despliegue

  • Patrón común: terminar OIDC en un proxy inverso (Apache mod_auth_openidc, Nginx, Caddy, Traefik) y reenviar la identidad mediante cabeceras a las apps, evitando la complejidad de OIDC por aplicación.
  • Algunos ejecutan Keycloak localmente sobre HTTP y lo exponen mediante túneles de Cloudflare o proxies con auto-TLS (Caddy, Caddy-Docker-Proxy) para evitar la gestión manual de certificados; otros prefieren Nginx en el host por su madurez y documentación.
  • Keycloak puede comportarse de forma extraña detrás de proxies; en algunas configuraciones ha hecho falta configuración adicional del proxy. Los desajustes de DNS en desarrollo local (hostname del contenedor vs localhost) son una molestia recurrente.

Soluciones alternativas de identidad/SSO

  • Authelia: elogiado por su huella muy pequeña, configuración simple con archivos/variables de entorno y SSO sólido en la capa de proxy para homelabs; carece de una UI completa de administración de usuarios. Hay preocupación por lanzamientos poco frecuentes; los mantenedores afirman que se desarrolla activamente con una gran preversión pendiente.
  • authentik: apreciado por la facilidad de configuración y la buena documentación, pero criticado por un error de redirección en subdominios y una implementación no estándar de client-credentials; los mantenedores lo reconocen y están publicando correcciones.
  • Zitadel: citado repetidamente como mucho más fácil que Keycloak, con todas las funciones MFA/passkey en la versión de código abierto; requiere su propia base de datos (Postgres).
  • Otros mencionados: Dex + oauth2-proxy (IdP federado simple + forward auth), FusionAuth (de código cerrado pero con nivel gratuito, amigable con Terraform), JetBrains Hub, obligator (dirigido por código, sin BD pero joven), Teleport, lldap como LDAP ligero.

Configuración, autorización y seguridad

  • Varios usuarios mueven la autorización (grupos/roles/permisos) fuera de Keycloak hacia bases de datos de aplicaciones o servicios de autorización dedicados, dejando Keycloak solo para la identidad.
  • Se usa infraestructura como código (por ejemplo, proveedores de Terraform) para evitar la configuración manual de Keycloak y la deriva.
  • Debate sobre la postura de seguridad: las CVEs de Keycloak preocupan a algunos; otros sostienen que la notificación transparente es mejor que fallos desconocidos en silencio. Se considera que los IdPs de código cerrado sin CVEs no garantizan seguridad.