简体中文
如何选择身份提供商：工程团队的评估框架
一个基于真实企业需求构建的实用 IdP（身份提供商）评估框架。涵盖协议深度、迁移、多租户、AI 准备度，以及多数清单未提及的关键标准。
Yijun
Developer
Developer
一个基于真实企业需求构建的实用 IdP（身份提供商）评估框架。涵盖协议深度、迁移、多租户、AI 准备度，以及多数清单未提及的关键标准。
大多数身份提供商对比文章都是身份提供商自己写的。令人震惊，对吧？他们会罗列自家产品有的功能，跳过没有的，然后美其名曰“客观指南”。
这篇不是那样。
我们审阅了数十份真实的企业评估需求——就是采购团队发给厂商的那些实际表格和 RFP 文件。规律很清楚：工程团队总是低估最重要的标准，高估最不重要的。
结果？团队基于演示选择了一个 IdP，六个月后发现迁移简直是噩梦，又开始重新评估。
这就是我们希望有人早早给我们的一套评估框架。它是为 B2B SaaS 公司的工程团队打造的——那些在构建产品的团队，而不是为员工采购 SSO 的。
如果你在扫读，以下是精要版：
本指南剩余部分会详细讲解每个维度的评估方式，给出具体问法和风险信号。
你适合看这个指南，如果：
你不适合用这个指南，如果：
市面上的每个 IdP 都会说自己支持 OAuth2 和 OIDC。这只是入门。真正的问题在于支持的深度。
必须有：
越来越关键：
很多团队没想到要问：你能把这个 IdP 用作 OIDC 提供方，而不只是 OIDC 消费方吗？
为何重要：SaaS 做大后，合作伙伴和客户可能希望用你的身份体系登录他们自家工具。你就必须能发 Token、管授权同意、支持第三方应用注册。如果 IdP 只能对接别人的身份系统，却做不了自己的 SSO 输出，想做外部联合登录就卡死。
要问：
Token 是 IdP 和服务之间的契约。如果不能自定义，所有后续服务都得多调用 API 才知道用户权限。
要问：
一个带有 { "org_id": "org_123", "role": "admin", "auth_level": 2 }的 token，API 中间件一行代码就能做授权。而只有 { "sub": "user_456" }的 token，每次都要回 IdP 或查数据库。大规模下，这就是每请求 2ms 和 200ms 的差距。
每个 IdP 都支持邮箱/密码和社交登录。恭喜你，你缩小到了……所有 IdP。
区分点在于那些演示绝不涉及的细节。
这部分是评估和演示拉开的最大差距。会话与 Token 管理很无聊，但一旦出问题，用户全体会掉线。
或许没啥光鲜亮丽，但绝对关键。
app.yourproduct.com、API 在 api.yourproduct.com，跨子域会话咋办？用户希望几周都免登录，但 180 天持久会话安全风险比 30 分钟高太多。
要问：
RBAC（基于角色访问控制）是底线。如果连 RBAC 都没有，不值得评估。B2B SaaS 里，仅 RBAC 远远不够。
你的用户属于不同组织。在每个组织里的权限和平台整体权限不同。
一个用户可以在甲组织是管理员，在乙组织是普通成员。用户相同、权限上下文不同。如果 IdP 不能原生建模，你最后会在应用写一套并行权限系统——双真源，灾难。
要问：
金融、医疗或风险高的操作时：认证会话不是全等的。
看报表？Cookies 会话即可。发起资金划转？就必须 MFA 新校验，即便登录状态还在。
这就是“晋级认证”，需要 auth_level 认证等级 成为 token 一级属性。
要问：
不支持这些，你得全自己造轮子——而买 IdP 就是为省这些身份逻辑。
理想情况：API 中间件看 Token 就知道用户组织、角色、认证级别，直接做授权，无需再查外部服务。
现实（大多数 IdP）：Token 只带用户是谁，允许做什么还得单独查 API。
多一次请求就多一分延迟和失效风险。每秒 1000 次认证，你不会想让授权因网络跳点而崩。
一个没人愿提的数字：大多数 IdP 评估不是因为新 IdP 不好而失败，而是团队搞不定用户迁移。
10 万用户下，迁移不是“锦上添花”，而是全部。
1. 批量导入现有密码 hash
你用户的密码都是用 bcrypt、argon2 等 hash 算法存储的。IdP 能否直接导入 hash 并按同算法校验？
若支持：用户无感，无需操作。最佳场景。
不支持：用户全收“重置密码”邮件。能流失 30-50% 用户。这不是假想，是真实案例。
2. 渐进/懒惰迁移
不是一把切，而是用户首次登录时动态迁移。第一次登录仍走旧系统，匹配后在新 IdP 创建账户，之后直接用新 IdP。
最安全最稳，但前提 IdP 要支持：
3. 双写/双活
迁移期，老新系统都活着。写入同步两边，读慢慢切到新。可回滚，但运维复杂。
这些答不上来的厂商，没实战，直接跳过。
B2B SaaS 标配多租户。你的客户都是组织，组织下有用户、角色和访问策略。IdP 必须原生支持这些。
有些 IdP 没有组织模型，只说“把 org_id 放用户自定义元数据”。
问题大了：
如果厂商说“多组织可以靠 metadata 实现”，就如拿 JSON 字段存关系列数据——能用，但迟早崩。
12 个月前，“AI agent 认证”没人关心。现在，如果你产品里要上 AI 特性（copilot、自动 agent、AI 驱动工作流），你的 IdP 必须能识别新身份类型：agent。
传统 auth 就俩角色：用户和应用。OAuth2 逻辑都是这个。
AI agent 带来第三方：一种非人类实体，代表某用户、有权限边界，还要完整审计记录。
Token 交换（RFC 8693）：agent 提交自己的凭证 + 用户授权，兑换出范围限定的 token。token 上要包括：谁（用户），什么（agent），scope（权限边界），何时（过期时间）。
agent 作为独立 client 类型：agent 要视为 OAuth2 客户端，有独立 client_id，绝不是用 API key 或共享用户 token 来模拟。
委托 scope 管理：用户能给 agent 授权具体权限（只读而非读写，只能访问部分资源等）。
审计区分度：日志必须区分“用户做 X”和“agent 代表用户做 X”。分不清将来问责出问题，SOC2 审计也会问“是谁改的？”
MCP 正成 AI agent 调用第三方服务的标准协议。IdP 若能支持基于 OAuth 的 MCP server，对 agent-to-tool auth 直接通用业界标准，比 API key/mock 强多了。
没考虑这些的供应商，产品还停留在 2020。你规划的产品是 2026。
功能能卖货，运营指标才决定你愿不愿续约。
按所有维度评估后，你需要一个实际可用的优先级方案：
| 标准 | 为什么是 P1 |
|---|---|
| 密码 hash 导入或渐进迁移 | 无法迁移就不能用 |
| 授权码 + PKCE | 安全底线 |
| 原生组织模型 | B2B SaaS 刚需 |
| SOC2 Type II 或明确路线图 | 企业客户要求 |
| 99.9%+ SLA | 认证挂了=产品全挂了 |
| 标准 | 为什么是 P2 |
|---|---|
| 自定义 JWT claims | 避免每次 API 权限查验 |
| 每租户认证策略 | 企业客户入驻体验 |
| 组织层角色和 token | 多租户权限模型刚需 |
| 刷新 token 轮换与吊销 | 安全最佳实践 |
| 托管 UI + 自定义 | 多场景灵活适配 |
| 标准 | 为什么是 P3 |
|---|---|
| Token 交换（RFC 8693） | AI agent 认证需求 |
| OIDC Provider 能力 | 合作方对接 |
| 步进认证/auth_level | 金融或敏感场景 |
| SCIM 自动同步 | 企业客户目录对接 |
| Passkey/WebAuthn | 无密码方向 |
| 标准 | 为什么是 P4 |
|---|---|
| 内置分析面板 | 审计日志可二次开发 |
| 白标邮件模板 | 易用性加分 |
| 可视化流程编辑 | 易用性加分 |
| 全部社交登录支持 | 长尾供应商 |
用法：P1 必选，淘汰任何 P1 不合格的厂商。再评分 P2、P3。P2+P3 总分高的为优先候选。
我们经常见到同样的坑。以下是“如何避免”：
特性列表只告诉你“有”，不告诉你“怎么做”。有的 IdP 把组织存在元数据里，表格上打钩，真到生产就是大雷。
解决：对每个特性都问“怎么实现”而不是只问“有/没有”。
先选了“最棒”的 IdP，开发一半发现不能迁移历史用户，还得全员重置密码。要么迁移体验灾难，要么评委再开。
解决：第一筛选项就看迁移能力。
供应商演示都是完美流程。干净数据库、零边角例外。你的生产环境用户字段有 emoji、合并过账号、还有已注销未清的会话。
解决：让对方用你自己的数据搞个 PoC（概念验证）。导入一千用户，完整跑一遍流程。
只有平台组评估会选技术最干净的。只有产品会选集成最容易的。只有安全组会选合规最多的。
解决：评估团队应涵盖平台、产品、安全。各自对 P1、P2 担责。
供应商锁定很现实。专有 SDK、自定义 API、非标 token 格式会直接增加以后迁出的成本。
解决：优先标准协议（OIDC、OAuth2、SCIM）的 IdP。将来迁移能少踩坑。
如需完整评估和概念验证（PoC），通常 4-8 周。赶工往往踩第二个坑，也就是忽略迁移。预算安排：需求梳理 2 周、厂商品评 + PoC 2-3 周、利益相关人对齐 1-2 周。
阶段不同答案不同。用户不到一万且没企业客户，用现成开源库即可。只要用上 SSO、多租户、MFA 和合规材料，自研维护成本就远高于 IdP 费用。见过团队常年养 2-3 个全职工程师手写认证，年成本 30-50 万美元起。
CIAM（客户身份管理）面向产品终端用户——注册、登录、个人中心。工作流 IAM 是你公司员工进内部工具用的（公司用 Okta 登录 Slack 等等）。两者采购逻辑和评估思路都不同。这份指南关注 CIAM。
开源 IdP 透明度高（能看代码）、可迁移性强（有需要可自托管）、有社区贡献。专有 IdP 通常 UI 更美观、SaaS 服务更管理。核心问题不是“开源还是闭源”，而是“我万一要迁能出得去吗”。开源的一般有标准数据/接口，换家厂商容易很多。
如果你马上就要做 AI 功能，且覆盖读写用户数据（copilot、自动流程、AI 助理），直接按 P1 要求。如果 AI 功能在 6-12 个月内上线，放 P3 但建议权重加大。如果暂时拍不到 AI，P4 即可，半年后再复盘。
绝大多数按 MAU（每月活跃用户）定价。但“活跃”的定义不同——有的算有登录就计，有的按去重，有的 M2M 另计。务必让供应商报你自己的场景：X 用户、Y 个组织、Z 条 M2M 连接和日常流量，然后算实际总价不要只看单价。
选型 IdP 是基础设施决策，不是功能对比。你押注的是一个系统，承载所有用户的首个操作、API 的每次权限检查和合规团队全部的审计分析。
上一整套实战评估框架，别只看市场宣传语。按优先级快速淘汰（P1），深入调查 P2、P3（最好 PoC），选出能用很多年而不仅仅是几个季度的方案。
真正做对的那些团队有个共同点：他们把身份管理当成基础设施，而不是“一次发布就忘了”的功能。