Keycloak SSO com Docker Compose e Nginx

Artigo original ↗ Discussão no Hacker News ↗

O single sign-on auto-hospedado com Keycloak provoca opiniões fortes: muitos valorizam seu rico conjunto de recursos e suporte a padrões, mas o descrevem como pesado, complexo de configurar e peculiar para operar em escala ou atrás de proxies reversos modernos. Os comentadores trocam dicas de implantação (Docker Compose, Nginx/Apache/Caddy, Terraform, exportação/importação de realms) e muitas vezes transferem a complexidade para a camada de proxy ou para serviços separados de autorização, ao mesmo tempo em que alertam sobre limites de desempenho e armadilhas operacionais como clustering e quantidade de realms. Uma ampla variedade de alternativas — Authelia, authentik, Zitadel, Dex, FusionAuth, plugins do Caddy e servidores OIDC mais leves — é comparada quanto à facilidade de configuração, consumo de recursos, suporte a MFA, abertura do código e adequação para homelab versus uso corporativo.

Keycloak: poder vs complexidade

  • Amplamente visto como poderoso e rico em recursos (OIDC/SAML, realms/tenants, serviços de autorização/UMA2), mas também grande, opinativo e difícil de aprender.
  • As reclamações incluem: interface/documentação confusas, APIs administrativas complicadas, exportação de configuração parcial/estranha, estado persistente que torna reconstruções complicadas e clustering difícil (descoberta multicast/UDP, sticky sessions).
  • Alguns relatam bom desempenho com a imagem Quarkus “optimized” (inicialização rápida, RAM modesta); outros veem inicializações lentas e alto uso de recursos. O tamanho do container e os recursos recomendados parecem pesados para homelabs simples ou configurações pequenas.
  • Realms são promovidos como mecanismo multi-tenant, mas há relatos de lentidão severa e falhas a partir de algumas centenas de realms; isso é descrito como um problema conhecido e antigo.

Proxy reverso e padrões de implantação

  • Padrão comum: encerrar OIDC em um proxy reverso (Apache mod_auth_openidc, Nginx, Caddy, Traefik) e encaminhar a identidade via headers para os aplicativos, evitando a complexidade de OIDC por aplicativo.
  • Alguns executam Keycloak localmente via HTTP e o expõem por túneis do Cloudflare ou proxies com auto-TLS (Caddy, Caddy-Docker-Proxy) para evitar gerenciamento manual de certificados; outros preferem Nginx no host pela maturidade e documentação.
  • Keycloak pode se comportar de forma estranha atrás de proxies; em algumas configurações, foi necessária configuração extra de proxy. Divergências de DNS no desenvolvimento local (hostname do container vs localhost) são uma irritação recorrente.

Soluções alternativas de identidade/SSO

  • Authelia: elogiado pela pegada muito pequena, configuração simples por arquivo/variáveis de ambiente e SSO forte na camada de proxy para homelabs; não possui uma interface completa de administração de usuários. Há preocupações sobre lançamentos pouco frequentes; os mantenedores afirmam que ele está sendo desenvolvido ativamente, com uma grande pré-versão pendente.
  • Authentik: apreciado pela facilidade de configuração e boa documentação, mas criticado por um bug de redirecionamento de subdomínio e por uma implementação não padrão de client credentials; os mantenedores reconhecem isso e estão entregando correções.
  • Zitadel: citado repetidamente como muito mais fácil que o Keycloak, com todos os recursos de MFA/passkey na versão open source; requer seu próprio banco de dados (Postgres).
  • Outros mencionados: Dex + oauth2-proxy (IdP federado simples + forward auth), FusionAuth (código fechado, mas com plano gratuito, amigável ao Terraform), JetBrains Hub, obligator (dirigido por código, sem banco, mas ainda jovem), Teleport, lldap como LDAP leve.

Configuração, autorização e segurança

  • Vários usuários movem a autorização (grupos/funções/permissões) para fora do Keycloak, indo para bancos de dados dos aplicativos ou serviços dedicados de autorização, mantendo o Keycloak apenas para identidade.
  • Infraestrutura como código (por exemplo, providers do Terraform) é usada para evitar configuração manual do Keycloak e drift.
  • Debate sobre postura de segurança: CVEs do Keycloak preocupam alguns; outros argumentam que o reporte transparente é melhor do que falhas desconhecidas silenciosamente. IdPs de código fechado sem CVEs são vistos como nenhuma garantia de segurança.