多数自托管身份系统的比较，一开始就把问题放错了位置。团队往往先打开功能表，去看谁支持 OIDC、SAML、SCIM、LDAP、passkey、社交登录。这样看当然有必要，可真正决定系统六个月后是否顺手的，通常在协议清单之外。身份系统最昂贵的部分，是应用接进来、委派管理员接进来、反向代理接进来，各种别扭边角也接进来之后，日常负担最后压在哪一层。

因此，Keycloak、authentik 与 ZITADEL 更适合被读成三种分工方式，少按三家围着同一张勾选表竞争来理解。Keycloak 把身份能力集中到以 realm 和 client 为中心的管理面里，identity brokering 与 user federation 很成熟，同时也默认你会把它放在 reverse proxy 后面，并认真处理集群会话。[1][2] authentik 走另一条路：它把自己定位为灵活的 IdP 与 SSO 平台，再借 outposts 把一部分逻辑往外推，让 proxy、LDAP、RADIUS、RAC 这些集成能力更靠近目标应用。[3][4] ZITADEL 的出发点又不同：instance、organization、project 一开始就是产品骨架，客户和租户分隔也跟着进入模型内部。[6][7][8]

真正值得先问的问题很简单：当身份系统从试点变成长期平台责任时，你希望责任集中在一个厚重的中心管理面里，分散到应用旁边的连接器与策略层里，还是从第一天起就按多租户层级来安排。

配图说明：题图是一把硬件安全密钥。它适合本文，因为身份架构最终都会走到登录、多因素认证与会话签发这最后一公里；管理后台在纸面上再整齐，也要在这里兑现。[10]

1. Keycloak 是集中化标准器

Keycloak 最适合的场景，仍然是平台团队明确想要一个大而清楚的中心。它的管理文档把核心概念写得很直接：realm、client、role、group、identity brokering、user federation，就是这套系统最常用的运维词汇。[1] 它适合那些希望很多应用从同一个地方继承身份策略的团队，也适合把身份系统当作共享平台服务，由平台团队统一收束各产品的差异。

这种中心化做法的优势在成熟度。Keycloak 可以 broker 外部 OpenID Connect 或 SAML 身份提供者，可以对接 LDAP 和 Active Directory，把多种上游身份关系收束到同一个系统里。[1] 若你的环境里已经有企业目录、多个上游身份源，或者一大批需要稳定协议处理的内部应用，这种覆盖面就很有价值。关键不在于它“功能更多”，而在于它本来就面向一个 server 式的统一运维中心。

代价也直接体现在运维上。Keycloak 的 reverse proxy 指南开门见山地讨论 reverse proxy、API gateway、load balancer，还明确写到端口、hostname 与 sticky sessions 等部署细节。[2] 选择 Keycloak，很少只是“开起来就行”。它更像一项需要平台团队长期托管的中心服务：入口、代理头、缓存行为、会话拓扑，都属于选型的一部分，也都会进入长期维护清单。[2]

换一种说法，Keycloak 最强的时候，组织内部早就已经存在一句很明确的话：我们需要一个服务很多应用的统一身份中心。

2. authentik 是替杂乱应用现场收口的灵活系统

authentik 的文档把自己定义成一个强调安全、灵活性与通用性的 IdP 和 SSO 平台。[3] 这层定位背后有具体产品做法，也确实不同于 Keycloak。authentik 允许一部分 provider logic 通过 outposts 这类可部署服务向外延伸，并与 authentik API 保持连接，让集成问题在更靠近应用的位置被处理。[4]

这一点很关键，因为真实的身份现场经常带着各种不规则接缝。有些应用只适合放在 proxy auth 后面，有些还停在 LDAP，有些需要 RADIUS，有些远程访问场景还要接 RAC。authentik 的 outposts 正是为这类情形准备的：官方文档明确写到，LDAP、Proxy、RADIUS、RAC 这些 providers 都需要 outpost，目的在于提高灵活性与速度，并把这部分逻辑从 authentik Core 中拆出去。[4] 它愿意把小型身份工作单元部署到协议摩擦真正发生的地方，在应用原位处理问题。

因此，authentik 在混杂应用现场里经常更自然，尤其是那些充满自托管应用、反向代理规则，或者希望强化登录策略但又不想重写目标服务的环境。它既是身份目录，也是一套替身份不原生的应用补齐策略与连接器的系统。

限制也要看清。authentik 确实提供 tenancy 功能，但它自己的文档把这一功能标为 alpha，并提醒读者不要把它与旧版本里的 brands 概念混为一谈。[5] 文档还说明，operator 可以借此创建多个 tenants，并为它们分配各自的 install ID 与 license。[5] 这当然有用，不过多租户 B2B 还没有成为这款产品较稳定的中心。若你的核心要求是“每个客户都要有清晰的组织分隔，委派管理也要长在主模型里”，authentik 往往不会排在第一位。它最强的路数，仍然是面对复杂应用现场时的灵活连接能力；tenant hierarchy 更靠后。

3. ZITADEL 是把租户层级放在前面的身份系统

若把视角从一般 SSO server 稍稍移开，ZITADEL 就清楚很多。它的文档把 instance、organization、project 放在正中。[6][7][8] 这一点会立刻改变选型逻辑。

organization 页面给出的信号最明显。文档直接写到，不同 organizations 的 settings 与 data 彼此分离，同时支持 delegation，让各个 organization 可以自行管理 IAM 的一部分；它还直接点明 B2B 场景：一个 organization 往往代表一个业务伙伴，这个伙伴可以有自己的 branding、access settings 或 federated login providers。[7] 这等于直接回答了“身份分隔该按什么划线”。

project 这一层又把问题讲得更实。ZITADEL 的项目文档说明，一个 organization 内可以有多个 projects，而同一 project 下的 applications 共享 roles、grants 与 role assignments。[8] 这使平台团队可以自然地区分“客户”“应用族”和“授权面”，不用把 realm 或 brand 反复拉扯到失真。若你卖的是面向别家组织的软件，需要委派管理，或者客户级身份设置本来就与产品形态紧紧绑定，这种优势会非常明显。[7][8]

它的运维面也比第一眼看上去更有主张。ZITADEL 的 Kubernetes 指南确实提供了带 optional PostgreSQL subchart 的快速起步方式，但同一份指南也明确要求 ingress controller、external domain、secret management 与多副本生产加固。[9] 因而，自托管 ZITADEL 仍然需要扎实的服务器运维；它只是更早、更清楚地说明系统跑起来以后，租户与项目该怎样摆放。

也正因如此，ZITADEL 最强的时候，组织内部那句更贴近现实的话会是：“我们的身份分隔必须对齐客户、组织和委派管理员。”

4. 一张够用的决策地图

在被协议覆盖面吸走注意力之前，先用下面这层过滤。

优先看 Keycloak 的情况：

• 你需要一个服务大量内部应用的集中式身份系统
• LDAP、Active Directory、上游身份 broker 处在需求中心[1]
• 平台团队愿意把 reverse proxy、集群与中心服务运维一起接下来[2]

优先看 authentik 的情况：

• 你的应用现场杂而不整，proxy auth、LDAP、RADIUS 这类集成问题非常真实[4]
• 登录策略的灵活性比租户层级的纯净性更重要[3][5]
• 你希望在必要时把身份相关组件部署到更靠近目标应用的位置[4]

优先看 ZITADEL 的情况：

• B2B 分工、委派管理、organization 分隔本来就是问题中心[7]
• 你需要把 applications 与 roles 清楚地挂在 project 级授权面之下[8]
• 你愿意接受一套更有主张的层级模型，因为它正好吻合业务分工[6][7][8]

5. 最容易犯的错误

最常见的误判，是把这三者都当成可以互换的“开源版 Auth0”。这样一压平，三种不同的运维模型就被误缩成了一个购物类目。

Keycloak 最适合那些想把身份系统集中标准化，并愿意一并承担基础设施成本的平台团队。[1][2] authentik 最适合那些压力来自杂乱应用现场、需要在边缘位置保留策略灵活度的团队。[3][4][5] ZITADEL 最适合那些 customer 与 organization 分隔处在核心位置，并且决定整套系统展开方式的团队。[6][7][8][9]

这里还可以点出一个证伪条件。若你的环境很小，应用都很现代，需求也只是一个 OIDC provider 加少量 social logins，那么上面的架构差异感受不会那么强，部署简洁度反而会更重要。可一旦委派管理、遗留协议、proxy auth 或 customer hierarchy 进入问题中心，这三套产品就会很快显出各自不同的负担形状。

来源

1. Keycloak documentation, "Server Administration Guide"（realm、client、identity brokering 与 user federation 结构）。
2. Keycloak documentation, "Configuring a reverse proxy"（reverse proxy、load balancer 与 sticky sessions 指南）。
3. authentik documentation, "Welcome to authentik"（作为强调灵活性的 IdP 与 SSO 平台的产品范围）。
4. authentik documentation, "Outposts"（LDAP、Proxy、RADIUS、RAC provider 逻辑部署到 authentik Core 之外）。
5. authentik documentation, "Tenancy"（alpha 功能边界与 operator 创建 tenants 的方式）。
6. ZITADEL documentation, "Instances"（身份系统的顶层结构）。
7. ZITADEL documentation, "Organizations"（分离、委派、branding 与 B2B partner 边界）。
8. ZITADEL documentation, "Projects"（organization 内的 applications、roles、grants 与 role assignments）。
9. ZITADEL documentation, "Deploy ZITADEL on Kubernetes"（ingress、database、secrets 与多副本生产部署要求）。
10. Wikimedia Commons, "File:YubiKey 5C NFC.jpg"（Marcin Kolakowski 拍摄，2026 年 1 月 29 日）。