Authentik vs ZITADEL vs Keycloak：自托管 SSO 对比

你的 VPS 上跑着八个 Docker 容器：Gitea、Nextcloud、Grafana、Vaultwarden、n8n、Portainer、一个状态页，还有一个你自己写的内部应用。每个都有各自的登录。你每天早上从密码管理器里复制粘贴密码，开始怀疑单点登录到底值不值得那份运维成本。

通常是值得的。问题在于该运行哪一个身份提供者。

Keycloak 是大家熟悉的默认选项，但更合适的选择取决于你的技术栈长什么样、你管理多少用户，以及你是在接入已有软件，还是在为自己的应用构建认证。

这篇自托管 SSO 对比从部署之后真正重要的决策出发来审视 Authentik、ZITADEL、Keycloak 和 Authelia：协议支持、用户管理、开发者工作流、资源需求，以及身份提供者宕机时会发生什么。

自托管 SSO 为什么重要

一旦多个应用依赖同一批人和同一批组，各自独立的登录就不再方便。自托管身份提供者让你在一个地方管理账号、MFA、组成员关系和访问策略，而不是在每个应用里各配一遍。

代价同样重要：IdP 会变成其他应用依赖的基础设施。它不可用时，新登录和令牌刷新都可能失败，所以备份、恢复访问、升级和可用性在这里比一个普通自托管应用重要得多。

TL;DR（太长不看版）

想要最佳默认选项，选 Authentik

对于通过 OIDC 或 SAML 接入现有应用的家庭实验室、内部工具栈或小团队，Authentik 是最稳妥的默认选项。它的管理流程比 Keycloak 更容易上手，支持多种集成方式，官方 Docker Compose 配置从 2 个 CPU 核心和 2 GB 内存起步。

在开发应用，选 ZITADEL

当认证是你正在构建的产品的一部分时，选 ZITADEL。它的组织模型、API、多租户、OIDC、SAML、通行密钥、MFA 和 LDAP 身份提供者支持，对 SaaS 和 B2B 应用团队比对典型家庭实验室更有意义。

需要企业级身份功能，选 Keycloak

当你需要更深入的 LDAP 或 Active Directory 联合、多个 realm、细粒度授权策略，或者环境本身已经围绕 Keycloak 搭建时，选 Keycloak。其文档建议为较小的生产级 Keycloak 容器设置 2 GB 内存上限；同时运行 PostgreSQL 的一体化 VPS 还需要额外余量。

当你的主要问题是在反向代理层保护应用，而不是运行一整套身份平台时，选 Authelia。它也能充当 OpenID Connect 提供者，但反向代理认证始终是它的重心。

选 SSO 工具之前要核对什么

在对比功能之前，先把每个工具和你已经需要支持的应用、协议和身份源逐一对照。

有多少应用需要 SSO？

从应用出发，而不是从身份提供者出发。六个已经支持 OIDC 或 SAML 的应用组成的技术栈，和一堆对这两种协议一无所知的老旧内部工具，是两个不同的问题。前者指向完整的 IdP，后者可能需要在反向代理层做认证。

你的应用支持 OIDC 或 SAML 吗？

OIDC 是现代 Web 应用的常见选择。SAML 在企业软件和较老的集成中仍然重要。当应用期望的是一个目录而不是基于 Web 的 SSO 流程时，LDAP 就有意义。在选择居中的 IdP 之前，先确认每个应用实际接受什么。

如果你的大部分工作是在管理界面里接入现有应用，Authentik 是自然的起点。如果认证是你正在构建的产品的一部分，并且你打算通过代码创建组织、用户和权限，ZITADEL 更贴近这种工作流。

你需要 LDAP、Active Directory 或高级策略吗？

Authentik、ZITADEL 和 Keycloak 都能以某种形式连接基于 LDAP 的身份源，所以单凭 LDAP 已经无法决定胜负。当目录联合与多个 realm、细致的映射器、同步需求或资源级授权策略结合在一起时，Keycloak 才会更有吸引力。

Authentik vs ZITADEL vs Keycloak vs Authelia

这四款工具在 SSO 上有重叠，但切入身份问题的方向不同：应用集成、产品身份、企业 IAM 和反向代理访问。

Authentik

Authentik 的核心部署由一个服务端、一个 worker 和一个 PostgreSQL 数据库组成。 Redis 已不再是技术栈的一部分：Authentik 在 2025.10 版本中彻底移除了这一依赖。当前的 Docker Compose 文档要求主机至少有 2 个 CPU 核心和 2 GB 内存。

决定性的特点是管理界面。Authentik 的流程引擎、应用配置和基于组的策略，比 Keycloak 更宽泛的配置模型更容易上手。如果你曾在 Keycloak 里配过一个 OIDC 应用，然后花时间排查令牌声明为什么缺失，这种差别很快就能感觉到。

它支持 SAML、OAuth2/OIDC、LDAP 和 RADIUS。对运行一组自托管应用的家庭实验室或小型工程团队来说，它是正确的默认选项。

ZITADEL

ZITADEL 主要用 Go 编写，采用 AGPL-3.0 许可证，目前处于 v4.x 版本线。部署包含一个 Go API、一个 Next.js 登录界面和 PostgreSQL，当前要求支持 PostgreSQL 14 到 18。官方 Docker Compose 文档要求主机至少有 2 GB 内存。

决定性的特点是 API。ZITADEL 通过 gRPC 和 REST 暴露完整的身份接口，并且从一开始就建立在多租户模型上。如果你在构建 SaaS 产品，并希望登录层可编程、可自动化、默认多租户，ZITADEL 比其他选项更接近你要的东西。

它支持 OIDC、SAML、通行密钥、MFA、LDAP 身份提供者，以及目前标记为 Preview 的 SCIM v2 接口。它的组织模型和 API 优先的工作流，使它更适合产品团队，而不是简单的家庭实验室。

Keycloak

Keycloak 是一个运行在 Quarkus 上的 Java 身份与访问管理平台。它的配置面比这里的其他选项都大，一旦涉及 Realms、Clients、Roles、用户联合和 Authorization Services 就更明显。

其官方容器文档建议为较小的生产级部署设置 2 GB 内存上限。这个数字只覆盖 Keycloak 容器本身；如果 PostgreSQL 共用同一台 VPS，就给主机留更多余量。

接受这种复杂性的理由是具体的。 Keycloak 可以联合 LDAP 和 Active Directory 目录，记录用户和管理员事件，并使用 RBAC、ABAC、基于用户、基于上下文等多种策略类型实施细粒度授权。如果你需要这些控制，额外的配置就有其意义。

Authelia

Authelia 是四者中最小的：Apache 2.0 许可证，单个 Go 二进制文件，目前版本为 v4.39.x。它的架构和另外三者不同：Authelia 位于反向代理（nginx、Traefik、Caddy、HAProxy）之前，决定请求能否到达后端。

Authelia 也内置了一个 OpenID Connect 提供者。其文档仍把 OIDC 实现描述为公开测试版，但该提供者已通过 Basic OP、Implicit OP、Hybrid OP、Form Post OP 和 Config OP 配置的 OpenID 认证。它的 OIDC 功能集比 Authentik 或 Keycloak 提供的身份管理功能更窄，这正是 Authelia 在反向代理认证是主要任务时依然最合理的原因。

我们会在单独的一节回到 Authelia。简而言之：Authelia 的重心是反向代理层的门禁，而不是完整的身份管理。

功能对比

下表只保留影响部署和日常管理的差异。

功能	Authentik	ZITADEL	Keycloak	Authelia
支持的协议	OAuth2/OIDC、SAML、LDAP、RADIUS、代理认证	OAuth2/OIDC、SAML、LDAP 身份提供者、SCIM v2（Preview）	OAuth2/OIDC、SAML、LDAP 与 Active Directory 联合	OIDC 提供者加反向代理认证
用户与组管理	用户、组、策略、流程、应用绑定	用户、组织、项目、角色、授权	用户、组、realm、客户端角色、realm 角色、联合	轻量级用户管理，通常以文件或 LDAP 为后端
开发者体验	有 API，但管理界面才是主要优势	API 优先，组织与多租户模型强大	成熟的 REST API，但需要学习更庞大的 IAM 模型	以配置文件驱动为主
企业级功能	策略、联合、outpost、应用访问控制	组织、项目、通行密钥、联合、SCIM v2（Preview）	深度联合、多个 realm、事件、Authorization Services	访问控制规则与紧密的反向代理集成
部署难易度	对大多数自托管应用栈来说更容易的起点	团队以 API 和产品身份思考时最合适	概念和配置更多，但控制更深入	主要任务是反向代理认证时最简单
资源建议	官方 Compose 下限：2 个 CPU 核心和 2 GB 内存	官方 Compose 主机下限：2 GB 内存	较小生产部署的建议容器内存为 2 GB	没有可直接对比的官方内存下限

哪个工具适合哪种技术栈？

围绕「你的技术栈需要什么」这一问题绘制的四款自托管 SSO 工具决策图：Authentik 适合家庭实验室、内部应用、小团队和 OIDC/SAML；ZITADEL 适合 SaaS、B2B、多租户和 API 优先的产品；Keycloak 适合企业 IAM、LDAP/AD、多个 realm 和高级策略；Authelia 适合为没有原生 SSO 的老应用做反向代理保护

最佳选择取决于谁来运维 IdP，以及应用如何与它集成。

家庭实验室的最佳选项

对于大多数应用已经支持 OIDC 或 SAML 的家庭实验室，Authentik 是默认选项。它提供完整的身份提供者，而不要求你采用 Keycloak 更宽泛的 IAM 模型。如果技术栈里大部分应用需要的是反向代理上的登录页而不是原生 SSO，Authelia 可能是更简单的选择。

小企业技术栈的最佳选项

Authentik 适合大多数小型内部应用栈，尤其是目标是为 Grafana、Gitea、Nextcloud 和 Vaultwarden 这类工具提供统一身份层的时候。当需求中包含现有目录、多个 realm 或更深入的授权策略时，Keycloak 会更有吸引力。

开发者与 SaaS 产品的最佳选项

当认证是你正在构建的产品的一部分时，ZITADEL 最合适。当用户和租户需要从应用代码而不是主要从管理面板创建时，它的组织模型、多租户、API 和自动化能力更有意义。

企业或合规要求高的团队的最佳选项

当需求清单包括复杂的目录联合、多个 realm、细致的授权策略，并且团队有能力运维额外的 IAM 复杂性时，Keycloak 是合理的。自托管 Keycloak 本身并不会让环境合规；备份、可用性、日志、访问审查和变更控制仍然是你的团队的责任。

没有原生 SSO 的应用的最佳选项

当认证必须在请求到达应用之前完成时，Authelia 是最明确的选择。它特别适合与反向代理配合，保护那些自身不支持 OIDC 或 SAML 的老旧内部工具、仪表盘和服务。

自托管 SSO 的难点

一旦 SSO 成为强制项，一次配置失误或一次失败的恢复就可能同时影响多个应用。

安装与配置

把容器跑起来只是第一步。DNS、TLS、重定向 URI、令牌声明、组映射、邮件投递和恢复访问，才是 SSO 部署从「又一个 Docker 应用」变成基础设施的地方。

服务器资源

IdP 只是资源预算的一部分。PostgreSQL、反向代理、worker、密码哈希、日志和目录同步在共用一台 VPS 时都会争抢 CPU 和内存。

数据库与备份管理

Authentik、ZITADEL 和常规的生产 Keycloak 部署都依赖数据库。把这个数据库备份到服务器之外，写清楚如何恢复，并实际测试恢复。一次成功的备份任务不等于一套可用的恢复流程。

锁死与恢复风险

一个错误的重定向 URI、一个过期的客户端密钥、一条断掉的目录连接或一条过于严格的策略，都可能把管理员和所有人一起锁在门外。保留一条不依赖于你正在修复的那条认证流程的恢复路径。

保持 IdP 可用

IdP 故障不一定会立刻终止所有现有应用会话。现有会话可能持续到各自的令牌或 Cookie 过期，但新登录和令牌刷新可能失败。在整个技术栈强制启用 SSO 之前，先测试这种故障模式。

什么时候不该自托管 SSO

当你的团队无法以应用所要求的可靠性恢复并运维身份层时，自托管就不再是一笔划算的买卖。

什么时候托管身份更安全

当运维 IdP 的成本高于自托管带来的控制权时，为托管身份付费是值得的。Auth0、Clerk、WorkOS 和 Microsoft Entra ID 这类服务把大部分平台可用性、补丁和基础设施维护转移给了服务商。

你仍然负责应用配置、权限和恢复规划，但不再需要负责让身份平台本身保持在线。

什么时候你的团队无法承受停机

如果团队里没有人能在故障期间恢复 IdP、修复 PostgreSQL、更换过期密钥或诊断失败的联合连接，自托管身份可能是错误的运维取舍。

这种故障不只是一个应用不可用。多个应用的新登录和令牌刷新可能同时失败。

什么时候合规要求太高

自托管身份可以用于受监管的环境，但自己运行软件并不会自动产生审计人员期望的控制措施或证据。日志、访问审查、备份、变更管理、可用性、事件响应，以及适用框架要求的所有文档，仍然由你的团队负责。

自托管 SSO 不是身份的象征。如果你的团队无法安全地运维身份层，为托管身份付费可能是更好的工程决策。

Cloudzy 能帮上什么

Cloudzy 改变的是部署层；它并不会免去上面描述的身份配置和运维工作。

手动部署 SSO 的问题

手动部署 SSO 意味着准备服务器、安装应用和数据库、配置反向代理、设置 DNS 和 TLS，然后才开始真正的身份配置。这些都替代不了之后的 OIDC、SAML、目录或策略工作。

在 Cloudzy 上一键部署 SSO

Cloudzy 提供 Authentik 和 Keycloak 的一键部署。 Authentik 一键应用已上架 Cloudzy 应用市场。 Keycloak 一键应用同样已上架 Cloudzy 应用市场。 ZITADEL 目前不在应用市场中，请在标准 VPS 上用它的 Docker Compose 配置部署。一键安装会把基础应用跑起来，而身份配置、DNS、备份、升级、策略和恢复测试仍由你掌控。

在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。

查看 Linux 套餐

什么时候该为 IdP 单独开一台 VPS

对于可以接受停机的家庭实验室，把 IdP 和应用放在一起是合理的。对业务关键的技术栈来说，把身份提供者分离出去可以消除一个明显的共享故障域：重启、耗尽或攻破应用服务器，不再意味着把身份层一并拖垮。

单独的 VPS 不等于高可用，但它给了 IdP 自己的资源预算、维护窗口和恢复边界。

VPS 配置建议

要按整个技术栈而不是只按 IdP 进程来配置资源，尤其是 PostgreSQL 和反向代理共用同一台 VPS 的时候。

Authentik 的 VPS 要求

Authentik 的官方 Docker Compose 文档要求主机至少有 2 个 CPU 核心和 2 GB 内存。这是小规模部署的正确起点。当 PostgreSQL、额外的 outpost、目录同步或更大的登录流量共用同一台主机时，给服务器留更多余量。

ZITADEL 的 VPS 要求

ZITADEL 的官方 Docker Compose 部署要求主机至少有 2 GB 内存。请把 ZITADEL、它的登录界面、PostgreSQL 和反向代理作为一个整体来规划一体化 VPS，而不是孤立地看 Go 服务。

Keycloak 的 VPS 要求

Keycloak 的容器文档建议为较小的生产级 Keycloak 部署设置 2 GB 内存上限。这个数字针对的是 Keycloak 容器本身，而不是同时运行 PostgreSQL 的整台 VPS。

如果 Keycloak 和 PostgreSQL 共用一台 VPS，4 GB 系统内存是一个合理的起点。把它当作实际的主机建议，而不是 Keycloak 的官方最低要求。

Authelia 的 VPS 要求

Authelia 没有公布可直接对比的 1 GB 或 2 GB 服务器最低要求。请把 Authelia 与反向代理、存储后端、用户目录以及共用这台机器的其他服务放在一起规划主机资源。

Authelia 的部署占用通常比一整套 IdP 加 PostgreSQL 小，但实际的 VPS 需求取决于技术栈的其余部分。

配置示例：Authentik 搭配 Vaultwarden

Vaultwarden 与 Authentik 之间的 OIDC 登录流程：用户登录 Vaultwarden，授权请求发往 Authentik，Authentik 处理登录、MFA 和身份校验并返回 ID、访问和刷新令牌，Vaultwarden 建立会话；图中标注了客户端 ID、客户端密钥、重定向 URI、签名密钥、邮箱作用域映射和 offline_access，并提醒在启用 SSO_ONLY 之前先测试

Vaultwarden 在 2025 年 12 月的 1.35.0 版本中加入了原生 OpenID Connect SSO 支持。 Authentik 是一个有用的示例，因为这次集成会把你在其他应用中同样会遇到的 OIDC 要素都暴露出来：重定向 URI、客户端凭据、作用域、签发者 URL 和恢复访问。

Authentik 基础设置

在 Authentik 中：

为 Vaultwarden 创建一个自定义的邮箱作用域映射。 Vaultwarden 要求 email 作用域要么返回 email_verified: true，要么完全不返回 email_verified 值，而 Authentik 默认的邮箱作用域目前返回的是 false。
创建一对 OAuth2/OpenID Connect 应用和提供者。
把 https://vault.example.com/identity/connect/oidc-signin 添加为严格匹配的 Authorization 重定向 URI。
选择任意一个可用的签名密钥。
记下 Client ID、Client Secret 和应用 slug。
把访问令牌有效期设置为大于五分钟。
把 Authentik 的 offline_access 映射添加到所选作用域中。
用第 1 步创建的自定义已验证邮箱映射替换默认的邮箱映射。

Vaultwarden 基础 OIDC 设置

使用：

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

把示例域名、应用 slug、客户端 ID 和客户端密钥替换为你自己部署中的值，然后重启 Vaultwarden。

强制启用 SSO 之前要测试什么

在测试登录、登出、令牌刷新、账号匹配和恢复期间，保持 SSO_ONLY 为 false。同时测试 Authentik 暂时不可用时会发生什么。

当 SSO 和恢复都按预期工作后，你就可以决定是否要在你的部署中要求每次登录都走 SSO。

同样的 OIDC 概念也适用于其他自托管应用，但重定向 URI、作用域、声明和许可证各不相同。请查阅每个应用自己的 SSO 文档，而不是直接照搬 Vaultwarden 的配置。

什么时候 Authelia 比完整的 IdP 更好

当应用完全不需要理解身份提供者时，Authelia 会更有吸引力。

反向代理认证

Authelia 主要是为在反向代理层保护应用而设计的。你定义访问控制规则，Authelia 在应用自己处理认证之前决定请求是否应该到达后端。

保护没有 OIDC 的应用

这对不支持 OIDC 或 SAML 的老旧内部工具、仪表盘和服务很有用。你不必修改每个应用，只需在反向代理上把认证放在它前面。

Authelia 也能充当 OIDC 提供者，但反向代理认证始终是它的主要优势。

把 Authelia 和 Authentik 搭配使用

你可以让 Authentik 负责支持 OIDC 或 SAML 的应用，让 Authelia 负责需要在反向代理做认证的应用。

你不一定两个都需要。Authentik 同样支持基于代理的应用保护，所以只有当 Authelia 的反向代理工作流能更干净地解决你技术栈里的某个具体环节时，把它搭配使用才有意义。

常见问题

Authentik 比 Keycloak 更好吗？

对大多数家庭实验室和小型自托管应用栈来说，Authentik 更容易上手。它的管理流程聚焦于应用、提供者、组和策略，不会一次性暴露那么多 IAM 复杂性。

当你明确需要 Keycloak 更深入的联合、realm 模型或 Authorization Services 时，Keycloak 更合理。对更简单的自托管 SSO，Authentik 是更稳妥的默认选项；Keycloak 适合需要这些额外控制的环境。

ZITADEL 比 Keycloak 更好吗？

当你在构建产品，并希望通过 API 驱动身份、组织和多租户时，ZITADEL 更合适。当你需要更深入的授权模型、广泛的联合控制，或者环境已经围绕 Keycloak 搭建时，Keycloak 更合适。

Authentik 和 Authelia 有什么区别？

Authentik 是围绕用户、组、应用、提供者、流程和策略构建的完整身份提供者。应用可以通过 OIDC 和 SAML 等协议直接与它集成。

Authelia 以反向代理层的认证和访问控制为核心。它也包含一个 OIDC 提供者，但反向代理保护始终是它的主要用途。

应用直接与 IdP 集成时选 Authentik。认证主要需要在流量到达应用之前完成时选 Authelia。

我能在 1 GB 的 VPS 上运行 Authentik 吗？

作为受支持的起点，不行。Authentik 当前的 Docker Compose 文档要求至少 2 个 CPU 核心和 2 GB 内存。当前的核心部署使用 Authentik 服务端、worker 和 PostgreSQL；Redis 已在 Authentik 2025.10 中彻底移除。

小规模安装请以 2 GB 作为最低起点，当其他服务共用这台机器时再增加余量。

Vaultwarden 支持 OIDC SSO 吗？

支持。Vaultwarden 在 2025 年 12 月的 1.35.0 版本中加入了 OpenID Connect SSO 支持。它需要一个外部 OIDC 提供者，比如 Authentik、Keycloak 或 ZITADEL。

具体配置取决于提供者。对于当前的 Authentik 版本，文档化的集成包括自定义的已验证邮箱作用域映射、offline_access、客户端凭据，以及 Authentik 应用的签发者 URL。

我该把 IdP 和应用放在同一台 VPS 上吗？

对于可以接受停机的家庭实验室，放在一起是合理的。对业务关键的应用来说，单独的 VPS 给身份提供者自己的资源预算，并把应用服务器从共享故障域中移除。

这本身并不会带来高可用，但应用服务器的重启、资源问题或被攻破不再会自动把 IdP 一起拖垮。

哪款自托管 SSO 最容易上手？

对大多数接入现有自托管应用的人来说，Authentik 是最容易的起点。它的管理界面让应用、提供者、组和策略比 Keycloak 更宽泛的 realm 和授权模型更容易掌握。

如果你只需要反向代理认证，Authelia 可能更简单。如果配置身份的人是主要通过 API 工作的开发者，ZITADEL 更合理。

讨论

登录后参与讨论。