keycloak/keycloak

如果你不介意自己运维一套身份服务，而不是把认证交给托管服务，Keycloak 值得认真评估。它上手门槛比想象中低：官方文档给了发行包解压运行 start-dev 和 Docker 镜像两条路，开发模式能很快起一个可登录的 realm。

解决什么问题

你想让一组内部或面向客户的应用共用登录入口，又不希望每个服务各写一套密码存储、会话和令牌签发。过去常见做法是把认证逻辑塞进每个应用，或者每个团队维护自己的用户表，结果账号和权限散落各处。Keycloak 把这件事收拢到中心服务：应用跳转到它完成登录，由它签发令牌、管理用户并做授权判断。你得到的是一个统一管理 OIDC 和 SAML 客户端账号的地方，而不是每个应用一套实现。

有什么不同

README 的说法是“不用自己处理用户存储和用户认证”，它放在同一个服务里的能力范围很宽：用户联邦、强认证、用户管理和细粒度授权，仓库主题同时列了 OIDC 与 SAML。实际分工大致是：应用开发者配置 client 和回调地址，管理员集中管理用户与角色，运维负责服务本身的数据库和配置。这种整合是主要收益——只有一道身份边界，而不是很多道。

代价是功能全面之后，它更像一个需要运营的产品，而不是一个接入即用的库。开发模式启动很容易，但真正上线意味着要维护数据库、谨慎管理 realm 和 client 密钥，并想清楚是否启用它的授权能力。安全状态也需要持续跟踪：2026-08-20 的 Hacker News 帖标题是“Keycloak unauthenticated account takeover via reset-credentials flow bypass”，这说明版本选择和漏洞报告流程都要认真对待（讨论帖、安全策略）。另外，2026-08-27 有一条评论称当时正在比较各家身份与 SSO 方案；这只是浏览过程中的一句闲谈，不是对 Keycloak 的评测（HN 评论）。

谁值得试

适合：有多个应用、想要自托管 SSO、集中管理用户并按角色或策略授权的团队，并且有人能负责这台服务及其数据库。不适合：只有一个很小的应用、只需要少量登录、更愿意把身份交给托管服务商的团队，或者不想额外运维一个有状态服务的团队。

使用条件与边界

README 同时记录了发行包下载和 Docker 镜像两种起步方式（快速开始、下载页）。开发模式只是快速看一眼的入口，不宜当作部署建议。装好之后，真正的长期要求是运维：用户、角色、realm 和 client 都在 Keycloak 服务里，备份与升级是你要承担的事。保护服务本身、跟进安全公告，也不是可选项。

HotRepo 点评

HotRepo 只有三个带日期的日榜观测：2026-06-27 为 35,156 星（+11），2026-06-28 为 35,389 星（+20），2026-10-28 为 37,566 星（+21）。这个样本不足以判断趋势；2013 年创建只能说明项目长期存在。决定采用前，建议先读你要运行版本的发布说明和安全策略；上面那个 reset-credentials 的帖子提醒你核对所选版本是否已包含修复，而不是把它当成安装步骤。