面向 B2B SaaS 开发者的最佳自托管 CIAM

如果你看过某些 SaaS 版 CIAM 平台的价格，多半已经注意到费用会涨得多快，也很可能考虑过改用自托管方案。

本文讲的是小型 B2B SaaS 团队真正能维护、又不会变成第二份全职工作的四个自托管 CIAM 平台：ZITADEL、FusionAuth、Logto 和 Ory Hydra。它们的形态并不相同，适合你的那一个更取决于你在做什么样的 B2B 产品，而不是一张功能清单。为了做这份对比，我把四者并排放在同一台 VPS 上跑了一周，下面就是我会直接发给私信问我 CIAM 的创业者的那个版本。

先说清楚一点：本文讲的是作为产品功能的 CIAM，而不是给自家团队用的内部 SSO。

简短版本

四个自托管 CIAM 平台，每个一句话：

• ZITADEL 如果你想开箱即用的多租户和 B2B 组织能力。
• FusionAuth 如果你想要打磨完善的管理界面和一段长期、可预期的发布历史。
• Logto 如果你想要第一天最清爽的开发者体验。
• Ory Hydra 如果你是在协议层做开发的人，要的是 OAuth 2.0 引擎，而不是一个已经替你做好决定的登录应用。

结论是：对典型的 B2B SaaS 来说，ZITADEL 是最稳妥的第一选择，本文余下的部分就是把这个理由拆开讲清楚。

为什么 CIAM 和员工 SSO 是两个不同的决策

如果内部团队的 SSO 挂了，损失通常是可控的。工程师可能有一个小时进不去 Grafana 或别的内部工具。可一旦 CIAM 挂了，付费客户就完全登录不了你的产品。这把问题从“哪个认证工具用起来对我们团队方便”变成了“哪个认证系统值得我们当作产品本身的一部分来信任”。

CIAM，也就是 B2B SaaS 需要的那类身份基础设施，还需要许多员工 SSO 工具并不强调的原语。你的客户不是单个用户，而是一个组织（一个租户），有自己的用户、角色、品牌，甚至可能有自己通往企业 IdP 的 SAML 连接。你不只是在认证人，而是在同一个产品里把一家公司的用户与另一家公司的用户隔离开。下面这四个工具各自以不同方式瞄准的，正是这种 B2B 形态。 Keycloak 现在已经有了一等公民级别的 Organizations，所以把它当成只适用于员工场景已经过时了；我在 FAQ 里解释为什么没有把它列入。

自建、外购还是自托管，这个三角在这里也长得不一样。从零写 OAuth 是自找的错误。你要交付的是 SaaS 产品，不是身份提供商。当团队完全没有运维余力、预算又合理时，买托管服务（Auth0、Clerk、WorkOS）就是正确选择。我绝不会让一个两人创业公司在第一天就自托管认证。自托管开始变得合理，是在托管 CIAM 的按 MAU 计价超过基础设施成本加上持续的工程时间时，或者你需要直接掌控部署和数据面时。在我合作过的团队里，这个拐点通常落在“我们有了真正的产品”和“我们有了真正的客户成功职能”之间。

如果你要找的是给自家应用用的 SSO，而不是给客户用的，那是另一场对比，不是这一篇。下面进入我们的首选。

四款工具，逐一来看

我挑这四个，是因为它们的形态足够像 CIAM，可以当作产品基础设施来评估，而不只是内部 SSO。ZITADEL、FusionAuth、Logto 和 Ory 都提供了真正可行的自托管路径，也有足够的使用量值得认真对待。那些只是库的方案、面向员工 SSO 的方案，以及成熟度不够的选项，放在 FAQ 里讲更合适。

ZITADEL

ZITADEL 是一个瑞士出品的身份平台，用 Go 编写，采用事件溯源架构和 PostgreSQL 后端。截至 2026 年 7 月 27 日，它在 GitHub 上的最新发布版本是 the 4.16 series, current as of July 2026。从 v3 开始，ZITADEL 由 Apache 2.0 转为 AGPL-3.0；对普通的 SaaS 用法来说，实际影响通常没有听起来那么吓人，细节我放在 FAQ 里讲。

ZITADEL 在 B2B SaaS 场景里的独到之处： 组织和多租户是一等公民级的原语，而不是你用通用对象拼出来的功能。你创建一个 Organization，它就有自己的用户、策略、品牌和访问设置，你还可以把项目授予该组织，让它的管理员为自家用户管理角色分配。你不必在通用用户之上再发明一个“租户”概念，一开始就有。

开发者体验是 API 优先的：既有当前的 v2 REST 资源 API，也保留了对旧版 v1 服务的 gRPC 和 REST 访问。官方和社区 SDK 覆盖了常见的服务端技术栈。管理控制台够用，但比 FusionAuth 的朴素一些。

我的判断： 如果你在做 B2B SaaS，而且清楚会有租户，我会从 ZITADEL 起步。在自托管选项里，它是最明确围绕 B2B 登录问题来设计的一个。

FusionAuth

FusionAuth 是 Inversoft, LLC（一家以 FusionAuth 名义经营的特拉华州 LLC）出品的美国平台，比另外三个存在得更久，而且这一点以好的方式显现出来。管理界面明显比其他几个更用心设计，文档成熟，发布节奏是稳而不是急。如果你接手过一套四年前写的认证集成，并在心里默默感谢前任工程师选了那个无聊的方案，那么 FusionAuth 就是配得上这份感谢的 CIAM。

真正绊人的是许可：FusionAuth Community 可以免费自托管，但核心产品并不是开源的。该产品受 FusionAuth 自有许可协议约束，而这些限制在你打算再分发、嵌入、换标、转售或替自家客户托管 FusionAuth 时就会变得重要。自托管的 Community 版覆盖了 B2B SaaS 的核心场景； 付费方案会追加功能 ，比如由 IdP 发起的 SAML、进阶 MFA 和按应用定制的主题；而 SCIM、Tenant Manager 以及应用级 MFA 策略则归在 Enterprise。

说到 B2B 形态：FusionAuth 建模了租户和应用，但它的抽象更像“按租户容器化的认证”，而不是“把 B2B 组织当作领域对象”。它能用（我在上面交付过产品），但多租户更像一个隔离原语，而不是一等公民的 B2B 模型。官方 SDK 和客户端库覆盖面很广：

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

服务端库都是很薄的 API 客户端。相比之下，它的管理控制台更容易交给非工程背景的运维同事使用。

我的判断： 如果你的团队更看重界面打磨和一段长期可预期的历史，而不是原生的 B2B 原语，那就选 FusionAuth。它是这里最“无聊”的选择，而这是一句赞美。

Logto

Logto 是四者中最年轻的，由 Silverhand Inc. 开发， 采用 MPL-2.0 许可，也是最明显在意自家仪表盘的一个。第一天的搭建相对很快：开好机器、点完向导，大约十五分钟就能跑起一个带体面默认登录界面的 OIDC 提供方（我在并排跑这四个的那一周实测过）。官方快速上手文档覆盖了主流框架和服务端技术栈，所以如果你的技术栈是“Next.js + Postgres + 某某”，会觉得很顺手。

它给出的 B2B 答案叫做 Logto Organizations。它覆盖了核心的 B2B 原语：组织成员关系、组织范围内的角色、成员邀请、即时开通，以及企业 SSO 集成。它的组织模型比 ZITADEL 的更年轻，所以任何不常见的 SAML、SCIM 或联邦流程，我都会先拿目标客户实测一遍再定下来。

代价是成熟度：Logto 是这里最新的一个。路线图跑得快，需要的功能落地时很爽，破坏性变更落地时就难受。如果你的 B2B SaaS 处在多租户光谱中比较简单的一端（组织数量不多、没有稀奇古怪的联邦需求），Logto 的开发者体验会让剩下的决策轻松许多。

我的判断： 如果你要的是最快的第一天，而且 B2B 需求还相对简单，那就选 Logto。

Ory Hydra（以及 Ory 技术栈）

Ory Hydra 是 Ory 生态中的 OAuth 2.0 / OpenID Connect 服务器， 采用 Apache-2.0 许可。完整的 Ory 技术栈把 Hydra 与 Ory Kratos（身份与用户管理、自助登录、注册、MFA 和账号找回）、Ory Keto（Zanzibar 风格的授权服务器，充当策略决策点）以及 Ory Oathkeeper（对进入的 HTTP 请求做认证、授权和改写的身份与访问代理）搭配在一起。你需要什么就组装什么。全部用 Go 编写，API 也很干净。

要注意的地方（这不是缺陷；对合适的团队反而是优点）在于，Hydra 是引擎，不是应用。按照设计， Hydra 会对接一个单独的登录与授权同意应用 ，而这个应用由你自己提供。如果你想要开箱即用的登录页面，这不是合适的工具。但如果你做的东西里认证流程本身就是产品的一部分（开发者平台、定制的 B2B 门户，或者带有专属引导流程的 API 优先产品），那么没有被规定死的界面恰恰正是你要的。

它的 B2B 故事是可组合的，而不是交钥匙的。你可以把 Kratos 的 schema 和 Keto 的关系接到自己的组织层上来建模多租户，这确实可行，但线是你自己连的。代价是更多的管道工作，回报是对体验的掌控。Ory 的文档把协议面讲得很深，但这种可组合模型默认你愿意自己在协议层面做决定。如果“audience claim”或“PKCE”对你毫无概念，那就先从另外三个里挑一个。

我的判断： 如果你在做协议层面的东西（认证网关、自定义流程、开发者平台），而标准应用让你觉得束手束脚，那 Ory 就是正确答案。对一个今天就想把登录跑起来的典型 B2B SaaS 来说，它不是。

一眼看懂的对比

下面是四款工具的一表汇总，适合第二遍回看，但不能替代上面的逐个介绍。

应该从哪一个开始？

四个简短的场景，基本覆盖了我会就此聊到的大多数团队。

你在做 B2B SaaS，而且清楚会有租户。 从 ZITADEL 开始。多租户和组织原语正是为这种场景设计的，API 面覆盖完整，你花在自造租户模型上的时间会比另外三个都少。转向 AGPL 值得做一次许可审查，但未经修改、单独集成的部署通常只是一个直白的 SaaS 用例。

你想要打磨完善的管理界面和一个稳定、可预期的平台。 选 FusionAuth。Community 方案能覆盖很多团队的核心需求；但要留出时间把许可协议和功能矩阵仔细读一遍。由 IdP 发起的 SAML、进阶 MFA 和按应用定制主题等功能需要付费方案，而 SCIM、Tenant Manager 以及应用级 MFA 策略则在 Enterprise 里。

你现在的 B2B 需求很简单，而且想要最快的第一天。 选 Logto。在我并排测试里，它第一天的开发者体验是最快的。接受你押注的是一个更年轻的生态，并且一旦需求长到你没测过的联邦边缘场景，就回过头重新评估这个选择。

你做的东西里，认证流程本身就是产品体验的一部分。 Ory Hydra（再加 Kratos，如果需要权限体系还要加 Keto）。你会写更多代码，也会拿到更多控制权。如果这笔交换对你来说不是一目了然的，那你就不是 Ory 的目标读者，去挑另外三个里的一个吧。

如果这些描述里有两条像在说你，那就默认选 ZITADEL。它的适配面最广，也是我可以不问太多追加问题就交给一个小创始团队的那一个。

自托管让你付出什么（运维层面）

接下来是这篇文章里最不浪漫的部分。

你的 PostgreSQL 备份纪律，现在成了业务赖以生存的东西。在这些部署里，你必须保护的身份状态可能包括用户记录、哈希后的凭据、MFA 密钥、OAuth 客户端凭据和会话数据。丢了这些状态，客户可能就再也登录不进来。在第一个真实用户注册之前就把自动备份配好，实际演练一次恢复，并把备份健康度放进和应用可用性同一个告警通道。

发布节奏会随时间变化。ZITADEL v4.16.1 在六月连续几次发布之后，于 2026 年 7 月 17 日推出；这里的每个项目都各自维持自己的节奏和兼容性策略。把这种节奏当成运维议题，而不是判断质量的捷径。在执行 docker compose pull 之前先读发布说明，并排定一个固定的打补丁窗口。把身份提供方的更新一拖数月，可能会让你在第一次正式审查时落后于安全和兼容性修复。

那些总在背后偷袭你的琐事：TLS 证书续期（用带 Let's Encrypt 的反向代理，把续期自动化，失败要告警）、发信服务的配置以便发出验证邮件和重置密码邮件（SES、SendGrid、Postmark 挑一个，把 SPF/DKIM/DMARC 配对，否则重置密码邮件会进垃圾箱）、有工程师离职时轮换 OAuth 客户端凭据，以及给登录端点加限流，免得一次撞库攻击把 CPU 打满。

小贴士：如果你用的是托管版 Postgres，别默认运行时的数据库用户也能建 schema。先把数据库和用户建好，授予必要的所有权或安装权限，再用每个工具期望的凭据跑第一次初始化。否则第一次运行可能会挂在一条含糊的数据库权限报错上，让你花一个小时追错方向。

自托管这条路在钱上替你省下的，会在“归属责任”上找你要回来。搭好之后，每个月留出几个工程小时来维持身份层的健康。完全不分配时间的团队，往往是后来才发现这笔成本：在一次故障中，在一个奇怪的 SAML 边缘场景里，或者在他们第一次安全审查上。

把它们部署在哪里

跑 Docker Compose 的 Linux VPS 可以是评估阶段和中等负载下一个合理的起点，但生产环境的容量规划和高可用取决于流量、安全要求，以及你对停机的容忍度。常见的部署方式定位如下：

• 共享主机 一个都跑不了。它们需要持久化存储、自定义端口、容器运行时所需的 root 权限，以及真正的数据库后端。这份清单里的大多数默认走 PostgreSQL，但严格来说它并不是每个工具唯一支持的数据库。
• Kubernetes 四个都能跑，但官方提供的路径参差不齐。 ZITADEL, FusionAuth，以及 Ory 都发布了官方 Helm chart，而 Logto 的自托管文档 把重心放在 Docker 和虚拟机部署上。对一个还没到「Kubernetes 在别处已经能自己回本」阶段的小型 B2B SaaS 来说，这通常属于过度工程。等你其余的基础设施本来就在上面时，再去用它。
• 裸金属 如果你本来就在裸金属上，那没问题。大多数 B2B SaaS 团队并不在。

做一个单节点的小型试点，我会从 4 GB 内存、2 vCPU 和 60 GB NVMe 存储起步，然后对真实的登录流程做压测。这是规划基线，不是放之四海皆准的生产最低配置。这些应用本身相对轻量，但 PostgreSQL 吃内存，密码哈希则需要 CPU 余量。 ZITADEL 的生产环境指南 建议为密码哈希的峰值预留四个 CPU 核心。

等产品真正跑起来、流量持续之后，按实测数据重新调整规格。快存储能改善 PostgreSQL 的延迟，而 CPU 余量在并发密码哈希时才见真章。别预设哪一项资源最关键，而要同时盯住内存、数据库 I/O、登录延迟和 CPU 饱和度。

把 CIAM 放到生产环境，就意味着它的可用性从此是你的问题。我们在这类工作负载上使用 Cloudzy Linux VPS 实例，配备 NVMe 存储，底层平台提供 99.95% 的可用性 SLA。Cloudzy 还提供 一键部署的 ZITADEL VPS ，适合你不想跑一遍初始的开通脚本时使用；另外三个都提供官方容器镜像，走 Docker 安装。如果想从管理者视角理解访问控制在整体安全态势中的位置， IAM 最佳实践指南 从策略角度讲清楚了这件事。

常见问题

ZITADEL 的 AGPL 许可会影响我的 SaaS 吗？

对未经修改、单独集成的部署来说通常不会，但这不是法律意见。ZITADEL 的 AGPL 义务适用于 ZITADEL 本身。如果你修改了 ZITADEL 并把修改版作为网络服务运营，许可可能要求你按 AGPL 提供相应源代码。ZITADEL 公开的立场是：仅仅把一个未修改的实例用作你 SaaS 的身份服务，本身并不要求你把独立的应用按 AGPL 授权。请阅读 ZITADEL 关于许可变更的公告 ，如果你要修改、再分发、嵌入或向第三方提供该软件，请咨询法律意见。另外也有商业许可可选。

为什么这份名单里没有 Keycloak 或 Authentik？

Keycloak 和 Authentik 都是很出色的自托管身份工具（我自己也在用），但如果因为「缺少 B2B 组织」而把 Keycloak 排除在外，如今就说不通了：当前版本的 Keycloak 已经包含 Organizations、组织分组和委派管理控制。我没有把它放进来，是因为这篇对比聚焦于四个对小团队 B2B SaaS 路径更直接的选项；当 JVM 运维、生态深度和 realm 级别的灵活性重要时，Keycloak 值得单独评估。Authentik 则仍然更适合员工和内部应用的 SSO，而不是产品原生的租户建模。

自托管比 Auth0 便宜吗？

在 MAU 较低时，通常不便宜。在早期创业公司这一档，你的工程工时比 Auth0 的账单更贵。自托管在经济上胜出的规模，是托管 CIAM 的按 MAU 计价超过「一台小 VPS + 你每月投入的那几个工程小时」之和的时候。确切的盈亏平衡点取决于团队的小时成本、MAU 增长曲线，以及产品是否需要那些把你推向 Auth0 更贵档位的企业功能。把这笔节省看作真实的，但不是立刻兑现的。

生产环境的 CIAM 最低需要多大的 VPS？

对单节点的小型试点来说，4 GB 内存、2 vCPU 加 NVMe 存储是合理的起点，而不是生产环境的保证。请按数据库体量、并发登录负载、密码哈希开销和可用性目标来定规格。ZITADEL 自己的生产指南建议为哈希峰值预留四个 CPU 核心；其他工具和其他流量形态需要各自做压测。

我以后能从托管 CIAM 迁移到自托管吗？

可以，但要当成一个正经项目来规划。密码重置并非不可避免：可导出性和支持的哈希格式各不相同，有些目标系统支持 批量或即时的用户迁移 ，另一些则必须重置。MFA 因子、OAuth 客户端、活跃会话、邮箱验证状态，以及租户或角色映射，都需要单独处理。如果你现在就隐约觉得以后会自托管，那就在挑选托管服务商之前，把这些导出与迁移方面的限制记录下来。