【身份与访问控制工程】自建还是采购：Keycloak、Auth0、Entra、Okta 对比

在 Keycloak 工程拆解 中，我们看到了自建 IAM 的工程细节。但很多团队面临的实际问题是：我们应该自建 Keycloak，还是直接买 Auth0/Okta/Entra？

这个问题不能被简化为”开源 vs 商业”的意识形态之争。它是工程经济学——总拥有成本（TCO）、团队能力、业务规模和定制需求的函数。

一、成本模型的工程拆分

IAM 的成本不仅是 license 费用。完整的成本模型包括：

TCO = License Fee
    + Infrastructure (compute + storage + network)
    + Operations (部署、监控、升级、故障处理)
    + Engineering (定制开发、集成、API 对接)
    + Knowledge (培训、文档、团队学习曲线)
    + Risk (供应商锁定、合规风险、供应商 outage)

1.1 自建 Keycloak 的成本

以一个中等规模的 B2B SaaS 公司为例（10 万 MAU，5 个企业 SSO 集成）：

隐性成本： - Keycloak 的版本升级不是零成本的——从 21.x 到 22.x 的 Quarkus 迁移，从 24.x 到 25.x 的 API 变更，都需要投入时间。 - Keycloak 的内部知识积累——团队中至少需要 1 人深入理解 Keycloak 的 SPI、Authentication Flow 引擎和数据库 schema。

1.2 采购 Auth0 / Okta 的成本

以 Auth0 的 B2B 定价为例（2026 年公开信息）：

1.3 盈亏平衡点

粗略估算：对于一个 MAU 在 5000 以下的 SaaS 创业公司，Auth0 的 Free Tier 或低端付费计划（~$300/月）远低于自建 Keycloak 的人力和基础设施成本（~$800/月）。

对于 MAU 在 10 万以上的 SaaS 公司，Auth0/Okta 的年费用（$30,000-$80,000/年）与自建 Keycloak 的一个专职 IAM 工程师的年薪（包含 on-call 和其他成本）处于同一量级。此时决策取决于其他因素——定制深度、数据主权、合规需求。

二、功能对比：不是什么都能互相替代

关键差异：

• Auth0 Actions vs Keycloak SPI：Auth0 Actions 是一个在登录流程中运行的 Node.js 函数，可以做轻量级的自定义逻辑（如 Whitelist 过滤、自定义 claims、发送通知）。但 Actions 不能实现”完全自己写一套认证流程”（如对接内部 HR 系统做实时身份验证）——这需要 Keycloak 的 SPI 深度扩展。
• Entra ID 的 AD 原生集成：如果企业已经全面依赖 Microsoft 365 和 Azure，Entra ID 的无缝集成（Azure AD Connect、Conditional Access、Intune 设备合规）是自建 Keycloak 无法复制的。
• Okta 的 Org2Org：大型企业集团可能已经统一使用 Okta——如果那些客户要求”我们只愿意接 Okta”，你作为 SaaS 提供商只需要支持 OIDC/SAML 即可，不需要自己成为 Okta 客户。

三、决策框架

flowchart TD
    Q1{"业务是 B2C<br/>还是 B2B？"}
    Q1 -->|"B2C<br/>(百万级用户)"| A1["采购 Auth0 / 云厂商方案<br/>自建 Keycloak 的运维成本<br/>在 B2C 量级下失控"]
    Q1 -->|"B2B<br/>(千-10万级用户)"| Q2{"是否需要深度定制<br/>或数据主权要求？"}

    Q2 -->|"需要"| Q3{"团队有 2+ 人<br/>能投入 IAM？"}
    Q3 -->|"有"| A2["自建 Keycloak<br/>+ 配合 OPA/Zanzibar"]
    Q3 -->|"没有"| A3["采购 Auth0 / Okta<br/>(企业级功能匹配)"]

    Q2 -->|"不需要"| Q4{"是否已全栈使用<br/>Microsoft/Azure？"}
    Q4 -->|"是"| A4["Entra ID<br/>(生态协同优势)"]
    Q4 -->|"否"| A3

    A1 -.->|"如果业务复杂度增加<br/>(如多租户权限)"| A2
    A3 -.->|"如果 MAU 增长到<br/>License 成本超过人力成本"| A2

工程判据：如果以下三个条件中满足两个，建议自建： 1. MAU > 50,000（商业 license 费用 > 一名 IAM 工程师的年薪）。 2. 需要深度定制认证流程（有自己的认证因素、与内部系统有复杂的实时交互）。 3. 数据主权或合规要求数据不得出特定区域（Auth0/Okta 的数据中心选择有限或不满足合规）。

四、迁移成本的事前评估

在选择”自建”或”采购”时，必须考虑切换成本：

• 自建 → 采购：迁移用户密码不可能（哈希不可逆），需要”渐变迁移”——新用户去新的 IdP，老用户在旧 IdP，逐步迁移或强制全员重新登录。
• 采购 → 自建：同样的问题反向——但可以导出用户数据（Auth0 和 Okta 都支持用户数据导出）。MFA 种子和 WebAuthn credential 不可迁移——必须让用户重新注册。
• 策略和权限数据：OAuth Clients 配置、权限规则（如果用了 OpenFGA/Zanzibar）可以在新平台重建，需要事前设计好自动化导入脚本。

上一篇：Keycloak 工程拆解：Realm、Client、Flow 与扩展机制 下一篇：CIAM 架构：面向 B2B / B2C SaaS 的身份平台