使用 Docker Compose 和 Nginx 搭建 Keycloak SSO
围绕自托管单点登录，Keycloak 引发了强烈分歧：许多人认可它丰富的功能和标准支持，但也认为它笨重、配置复杂，并且在大规模或放在现代反向代理后面运行时会出现各种怪癖。评论者分享了部署经验（Docker Compose、Nginx/Apache/Caddy、Terraform、realm 导入/导出），并常常把复杂性转移到代理层或独立的授权服务，同时提醒性能上限和运维陷阱，例如集群与 realm 数量问题。与此同时，Authelia、authentik、Zitadel、Dex、FusionAuth、Caddy 插件以及更轻量的 OIDC 服务等替代方案，则被从易用性、资源占用、多因素认证支持、代码开放程度以及是否适合 homelab 或企业场景等角度进行比较。
Keycloak：强大 vs 复杂
- 普遍被认为功能强大、特性丰富（OIDC/SAML、realms/tenants、authorization services/UMA2），但同时体量大、带有强观点，并且难学。
- 常见抱怨包括：UI/文档令人困惑、管理 API 繁琐、配置导出不完整或别扭、由于有状态而导致重建困难，以及集群部署困难（multicast/UDP 发现、sticky sessions）。
- 有人表示使用“optimized” Quarkus 镜像性能不错（启动快、内存占用适中）；也有人看到启动缓慢和资源消耗高。对于简单的家庭或小型部署来说，容器大小和推荐资源显得很重。
- Realms 被宣传为多租户机制，但有报告称在几百个 realms 左右会出现严重变慢和故障；这被描述为一个已知的长期问题。
反向代理与部署模式
- 常见模式：在反向代理层终止 OIDC（Apache mod_auth_openidc、Nginx、Caddy、Traefik），再通过 header 将身份信息转发给应用，从而避免每个应用都处理 OIDC 的复杂性。
- 有些人会在本地通过 HTTP 运行 Keycloak，并借助 Cloudflare 隧道或自动 TLS 代理（Caddy、Caddy-Docker-Proxy）对外暴露，以避免手动管理证书；也有人偏好在宿主机上使用 Nginx，因为它更成熟、文档更完善。
- Keycloak 在代理后面可能表现得很奇怪；在某些部署中需要额外的代理配置。容器主机名与 localhost 不一致的本地开发 DNS 不匹配问题，也是反复出现的烦恼。
替代的身份/SSO 方案
- Authelia：因极小的占用、简单的文件/env 配置，以及对 homelab 很强的代理层 SSO 能力而受到称赞；但缺少完整的用户管理 UI。有人担心其发布不频繁；维护者表示它仍在积极开发中，并且即将推出一个重要的预发布版本。
- Authentik：因易于搭建和文档良好而受到认可，但也因一个子域重定向 bug 以及非标准的 client-credentials 实现而受到批评；维护者承认这些问题并正在发布修复。
- Zitadel：多次被提到比 Keycloak 容易得多，且开源版本中包含全部 MFA/passkey 功能；但它需要自己的数据库（Postgres）。
- 其他提到的方案：Dex + oauth2-proxy（简单的联合 IdP + forward auth）、FusionAuth（闭源但有免费层，适合 Terraform）、JetBrains Hub、obligator（代码驱动、无数据库，但还很年轻）、Teleport、以及作为轻量 LDAP 的 lldap。
配置、授权与安全
- 一些用户把授权（groups/roles/permissions）从 Keycloak 中移出，放到应用数据库或专门的授权服务中，只保留 Keycloak 负责身份认证。
- 基础设施即代码（例如 Terraform provider）被用来避免手动配置 Keycloak 以及配置漂移。
- 关于安全姿态存在争论：Keycloak 的 CVE 让一些人担忧；另一些人则认为，透明地报告漏洞比默默存在未知缺陷更好；而没有 CVE 的闭源 IdP 并不能保证安全。