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

因此，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 本身就是产品结构的中心，因此 customer 与 tenant 的边界从一开始就在模型内部。[6][7][8]

放在这个层面上，真正值得先问的问题很简单：当身份系统不再是 pilot，而变成一项长期平台责任时，你希望这份责任落在一个厚重的中心管理面里，落在应用旁边的连接器与策略层里，还是从第一天起就落在多租户层级本身里。

配图说明：题图是一把硬件安全密钥。它适合本文，一方面因为与认证链路直接相关，另一方面也提醒人，身份架构只有在策略真正抵达登录与会话签发这最后一公里时，才算落地。[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 明显不同。它允许一部分 provider logic 通过 outposts 这类可部署服务向外延伸，并与 authentik API 保持连接，让集成问题可以在更靠近应用的位置被处理。[4]

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

因此，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 的情况：

优先看 authentik 的情况：

优先看 ZITADEL 的情况：

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 日）。