如何选择身份提供商：工程团队的评估框架

大多数身份提供商对比文章都是身份提供商自己写的。令人震惊，对吧？他们会罗列自家产品有的功能，跳过没有的，然后美其名曰“客观指南”。

这篇不是那样。

我们审阅了数十份真实的企业评估需求——就是采购团队发给厂商的那些实际表格和 RFP 文件。规律很清楚：工程团队总是低估最重要的标准，高估最不重要的。

结果？团队基于演示选择了一个 IdP，六个月后发现迁移简直是噩梦，又开始重新评估。

这就是我们希望有人早早给我们的一套评估框架。它是为 B2B SaaS 公司的工程团队打造的——那些在构建产品的团队，而不是为员工采购 SSO 的。

快速结论：IdP 选型的关键因素#

如果你在扫读，以下是精要版：

1. 协议深度比功能数量更重要。 很多 IdP 声称支持“OAuth2”，实际上没什么意义。支持哪些授权类型？Token claims 能自定义吗？你能让自己变成 OIDC 提供商吗？
2. 迁移能力是最被低估的第一标准。 如果你无法迁移已有用户（无需强制重置密码），这个 IdP 就不能用——不管其他方面多完美。
3. 多租户必须是原生支持，而非外挂。 如果组织模型和每租户配置都需要各种变通方法，你以后会一直和系统作斗争。
4. AI 准备度不是未来规划——它是一年内的需求。 Token 交换、代理身份、授权委托。如果 IdP 不支持，明年你还得再评估一次。

本指南剩余部分会详细讲解每个维度的评估方式，给出具体问法和风险信号。

适用对象（和不适用对象）#

你适合看这个指南，如果：

• 你是 50~300 人 B2B SaaS 公司的 CTO、工程副总裁或平台架构师
• 你有 10 万以上现有用户，承受不起激烈的迁移中断
• 你开始做面向企业客户，需要 SSO、组织模型和审计日志
• 你需要写技术评估报告，并想要不来自厂商的评估框架

你不适合用这个指南，如果：

• 你要找的是工作流身份管理（员工 SSO 进内部工具）——那是另一种选型
• 你是初创企业，只有 500 用户且还没企业客户——选 SDK 好、集成快的 IdP
• 你需要身份验证（KYC/KYB）——那是完全另一个类别

维度1：协议能力——不能只看“支持 OAuth2”#

市面上的每个 IdP 都会说自己支持 OAuth2 和 OIDC。这只是入门。真正的问题在于支持的深度。

授权类型：都支持哪些、为何重要#

必须有：

• 授权码 + PKCE —— 浏览器和移动端唯一应该用的方式。如果厂商还推荐 Implicit flow，可以直接淘汰。PKCE 不是可选，是安全要求。
• 客户端凭证（Client Credentials） —— 用于服务对服务的通信。你的后端服务需要在没有用户在场时相互认证。
• 刷新 Token —— 听起来基础，具体实现差距巨大。Token 能否支持轮换？能否设置有效期？能否只吊销单个刷新 Token 而不是全清会话？

越来越关键：

• Token 交换（RFC 8693） —— 支持 AI agent 认证、模拟登录、授权委托。如果没有，问 roadmap。没 roadmap 就是大红旗。

OIDC Provider 能力#

很多团队没想到要问：你能把这个 IdP 用作 OIDC 提供方，而不只是 OIDC 消费方吗？

为何重要：SaaS 做大后，合作伙伴和客户可能希望用你的身份体系登录他们自家工具。你就必须能发 Token、管授权同意、支持第三方应用注册。如果 IdP 只能对接别人的身份系统，却做不了自己的 SSO 输出，想做外部联合登录就卡死。

要问：

• 有 OpenID Discovery 接口可做白标吗？
• 能为第一方和第三方应用注册分级信任吗？
• 第一方能跳过授权同意页面，第三方必须展示吗？

JWT 自定义#

Token 是 IdP 和服务之间的契约。如果不能自定义，所有后续服务都得多调用 API 才知道用户权限。

要问：

• 能给 access token 和 ID token 添加自定义 claims 吗？
• 能把组织信息（用户当前在哪个租户下操作）直接放进 token 吗？
• 能自定义 scopes 映射到业务权限模型吗？
• Claims 是签发时计算，还是能通过 webhook/脚本动态生成？

一个带有 { "org_id": "org_123", "role": "admin", "auth_level": 2 }的 token，API 中间件一行代码就能做授权。而只有 { "sub": "user_456" }的 token，每次都要回 IdP 或查数据库。大规模下，这就是每请求 2ms 和 200ms 的差距。

维度2：认证流程——细节才是致命点#

每个 IdP 都支持邮箱/密码和社交登录。恭喜你，你缩小到了……所有 IdP。

区分点在于那些演示绝不涉及的细节。

注册流程#

• 注册后自动登录：用户注册后会直接登录，还是要再进一次登录页？注册后还要重新登录会极大影响转化率。很多 IdP 这里会出错。
• 自定义注册字段：能否在注册时采集角色、公司名称、用例？还是得后续专门做一套入职流？
• 渐进型完善资料：能否分多次会话补全资料，而不是一次全收？

登录流程#

• login_hint 支持：用户从营销邮件点进来，能否自动填好邮箱？看似小事，实际上能影响营销转化率 20%。
• 组织级认证策略：甲组织可要求 SAML SSO，乙组织用邮箱/密码，企业客户定制 MFA。每租户认证策略要是必须改代码而不能在配置上做，你每接一个新客户就要多写一次代码。
• 品牌定制：能否 per-tenant 定制登录体验？不只是 Logo、主色，而是完整 CSS、独立域名、白标邮件。应该是“托管 UI 还是自定义 UI”你选，而不是 IdP 限制你选。

多数清单遗漏的点#

• 无感静默认证：Token 过期，应用能否静默刷新，而不是重定向用户？刷新 Token 也过期怎么办——比如 iframe 滑动会话？
• 账号绑定：用户先用 Google 注册，再用邮箱登录。这俩是两个账号还是能合一？IdP 的账号合并怎么做？做不好会永远有幽灵账号。
• 无密码认证方式：魔法链接、passkey、WebAuthn。未必现在就全要，但半年内企业客户一定会问。

维度3：会话与令牌管理——真正的深水区#

这部分是评估和演示拉开的最大差距。会话与 Token 管理很无聊，但一旦出问题，用户全体会掉线。

Cookie 安全性#

或许没啥光鲜亮丽，但绝对关键。

• HttpOnly、Secure、SameSite 属性：这三个属性缺一不可。不设置 HttpOnly 的 IdP 就不该进生产。
• 跨子域支持：假如你的 app 在 app.yourproduct.com、API 在 api.yourproduct.com，跨子域会话咋办？
• 第三方 Cookie 淘汰：Chrome 即将禁用。IdP 在不靠第三方 cookie 怎么做跨域认证流？如果回答是“我们正在开发”，那还不够。

记住我与持久会话#

用户希望几周都免登录，但 180 天持久会话安全风险比 30 分钟高太多。

要问：

• 能把会话时长和 token 有效期分开配吗？
• 有无“记住我”选项能延长会话但令牌还可短？
• 对敏感操作能强制二次认证但不注销主会话吗？

刷新 Token 安全性#

• Token 轮换：每用一次就换 Token 吗？（必须）
• 存储加密：Token 在服务端静态加密存储吗？
• 吊销粒度：能否单独吊销一台设备的会话？
• 过期策略可配：不同应用有不同 Token 有效期，能 per-app 单独设置吗？还是全局？

维度4：授权模型——不仅仅是 RBAC#

RBAC（基于角色访问控制）是底线。如果连 RBAC 都没有，不值得评估。B2B SaaS 里，仅 RBAC 远远不够。

组织范围权限#

你的用户属于不同组织。在每个组织里的权限和平台整体权限不同。

一个用户可以在甲组织是管理员，在乙组织是普通成员。用户相同、权限上下文不同。如果 IdP 不能原生建模，你最后会在应用写一套并行权限系统——双真源，灾难。

要问：

• 能否在组织层面定义角色，而不仅仅是用户？
• 单个用户能在不同组织下有不同角色吗？
• 当前组织上下文能进 Token 里，让 API 知道用哪个 org 的数据？

多级授权（auth_level）#

金融、医疗或风险高的操作时：认证会话不是全等的。

看报表？Cookies 会话即可。发起资金划转？就必须 MFA 新校验，即便登录状态还在。

这就是“晋级认证”，需要 auth_level 认证等级 成为 token 一级属性。

要问：

• Token 能带 auth_level 字段后端校验吗？
• 应用能透传触发晋级认证，而不用强制全会话重新登录？
• auth_level 有独立有效期可配吗？

不支持这些，你得全自己造轮子——而买 IdP 就是为省这些身份逻辑。

基于 token 的授权判定#

理想情况：API 中间件看 Token 就知道用户组织、角色、认证级别，直接做授权，无需再查外部服务。

现实（大多数 IdP）：Token 只带用户是谁，允许做什么还得单独查 API。

多一次请求就多一分延迟和失效风险。每秒 1000 次认证，你不会想让授权因网络跳点而崩。

维度5：迁移——决策成败分水岭#

一个没人愿提的数字：大多数 IdP 评估不是因为新 IdP 不好而失败，而是团队搞不定用户迁移。

10 万用户下，迁移不是“锦上添花”，而是全部。

三类迁移方案（IdP 必须支持）#

1. 批量导入现有密码 hash

你用户的密码都是用 bcrypt、argon2 等 hash 算法存储的。IdP 能否直接导入 hash 并按同算法校验？

若支持：用户无感，无需操作。最佳场景。

不支持：用户全收“重置密码”邮件。能流失 30-50% 用户。这不是假想，是真实案例。

2. 渐进/懒惰迁移

不是一把切，而是用户首次登录时动态迁移。第一次登录仍走旧系统，匹配后在新 IdP 创建账户，之后直接用新 IdP。

最安全最稳，但前提 IdP 要支持：

• 可挂自定义认证 hook 调旧系统
• 登录时可动态创建用户
• 能记录哪些用户已迁移、哪些未迁移

3. 双写/双活

迁移期，老新系统都活着。写入同步两边，读慢慢切到新。可回滚，但运维复杂。

迁移风险信号#

• “支持 CSV 导入” —— 仅能导用户，不会导 hash。依旧要全重置密码。
• “我们有迁移指南” —— 仔细读，里边若说“用户必须重设密码”，那就是流失 30-50% 用户。
• 没提 hash 兼容性 —— 厂商没参与过大规模迁移项目。

要问的问题#

• 支持哪些密码 hash 算法导入？（bcrypt、argon2、scrypt、PBKDF2、自定义？）
• 能做渐进迁移吗？首登迁用户？
• 能追踪迁移进度吗？百分比统计？
• 迁移失败怎么回滚？
• 迁移期会话能不断吗？用户不必重新登录吗？

这些答不上来的厂商，没实战，直接跳过。

维度6：多租户——原生还是外挂#

B2B SaaS 标配多租户。你的客户都是组织，组织下有用户、角色和访问策略。IdP 必须原生支持这些。

“原生多租户”含义#

• 组织是一级实体：不是用户 profile 的一个自定义字段，而是独立模型、独立 ID、配置和成员管理。
• 每组织认证策略：甲用 SAML SSO，乙邮箱/密码 + 必须 MFA，丙用 Google 登录。都能 UI 或 API 设置，不要改代码。
• 组织邀请/成员管理：每个 org 管理员可邀成员、分配角色、踢出账号。IdP 处理邀请、邮箱验证、角色分配。
• 组织范围 token：用户操作某 org 时，token 带 org 上下文。API 区分该返回哪个 org 的内容。

“自定义元数据”曲线救国#

有些 IdP 没有组织模型，只说“把 org_id 放用户自定义元数据”。

问题大了：

• 用户多 org 需数组管理
• 邀请、成员流全得自己写
• 无 per-org 认证策略
• token 无组织上下文，需靠别的方式还原
• 审计日志不识别组织维度

如果厂商说“多组织可以靠 metadata 实现”，就如拿 JSON 字段存关系列数据——能用，但迟早崩。

要问的问题#

• 组织模型是原生还是靠元数据？
• 用户能否属于多个 org？
• 组织级认证策略能否配置？
• 组织级角色、权限原生支持吗？
• 组织管理员可以自助管理成员吗？
• token 能包含组织上下文吗？

维度7：AI 准备度——现在还没人问的未来刚需#

12 个月前，“AI agent 认证”没人关心。现在，如果你产品里要上 AI 特性（copilot、自动 agent、AI 驱动工作流），你的 IdP 必须能识别新身份类型：agent。

代理身份打破传统模型#

传统 auth 就俩角色：用户和应用。OAuth2 逻辑都是这个。

AI agent 带来第三方：一种非人类实体，代表某用户、有权限边界，还要完整审计记录。

• agent 不是用户，无密码、无浏览器会话
• agent 不是机器对机器服务，它代表具体某个用户
• agent 需要范围有限、时效短的委托权限——不能拿到用户全部权限

IdP 必须支持的特性#

Token 交换（RFC 8693）：agent 提交自己的凭证 + 用户授权，兑换出范围限定的 token。token 上要包括：谁（用户），什么（agent），scope（权限边界），何时（过期时间）。

agent 作为独立 client 类型：agent 要视为 OAuth2 客户端，有独立 client_id，绝不是用 API key 或共享用户 token 来模拟。

委托 scope 管理：用户能给 agent 授权具体权限（只读而非读写，只能访问部分资源等）。

审计区分度：日志必须区分“用户做 X”和“agent 代表用户做 X”。分不清将来问责出问题，SOC2 审计也会问“是谁改的？”

MCP（模型上下文协议）兼容性#

MCP 正成 AI agent 调用第三方服务的标准协议。IdP 若能支持基于 OAuth 的 MCP server，对 agent-to-tool auth 直接通用业界标准，比 API key/mock 强多了。

要问的问题#

• 支持 OAuth2 Token 交换吗？
• agent 能否为独立 client 类型建模？
• token 能否承载委托信息？（谁授权 agent，scope）
• 审计日志能区分代理和真人操作吗？
• 有 MCP 兼容或 OAuth 接入 agent-to-tool 场景吗？

没考虑这些的供应商，产品还停留在 2020。你规划的产品是 2026。

维度8：非功能性需求——那些让你夜不能寐的点#

功能能卖货，运营指标才决定你愿不愿续约。

性能指标#

• 认证吞吐量：高峰能顶到每秒百次、千次请求吗？
• Token 校验延时：服务本地校验 JWT（最佳），否则如果得查 introspection，99分位延迟是多少？
• 扩展上限：支持的最大 MAU（每月活跃用户）是多少？有无案例证明？

合规#

• SOC2 Type II：不是 Type I。Type II 代表被连续审计，Type I 只看过某一时间。只有 I 就问 II 的时间表。
• 审计日志：每个认证事件、权限变更和管理操作都上链，可导出到 SIEM，且日志不可改。
• 数据驻留：能指定用户数据在哪个地区？对欧盟客户是硬要求。

可靠性#

• SLA：99.9% 听上去好，可那是一年 8.7 小时宕机。99.99% 只 52 分钟。身份系统就是产品的门槛，差别巨大。
• 容灾：供应商宕机时咋办？有备选方案？多区部署？
• 故障历史：查供应商状态页，别只听承诺，看实际事故。

数据可迁移性#

• 用户导出：能否导出全部用户数据、元数据、组织、角色？格式标准吗？
• 协议标准化：是否用 OIDC、SCIM 等通用协议，便于以后迁移？
• 无锁定信号：自定义 API、非标协议、token 格式非标准都意味着锁定，迁移一次就很难。

评估矩阵：实用的打分框架#

按所有维度评估后，你需要一个实际可用的优先级方案：

P1——硬退出项（必须通过否则淘汰）#

P2——强烈建议（缺失将大幅加工作量）#

P3——重要（要在 12 个月内规划）#

P4——加分项（不会决定成败）#

用法：P1 必选，淘汰任何 P1 不合格的厂商。再评分 P2、P3。P2+P3 总分高的为优先候选。

常见选型误区#

我们经常见到同样的坑。以下是“如何避免”：

误区1：只看功能不看架构#

特性列表只告诉你“有”，不告诉你“怎么做”。有的 IdP 把组织存在元数据里，表格上打钩，真到生产就是大雷。

解决：对每个特性都问“怎么实现”而不是只问“有/没有”。

误区2：选型后才考虑迁移#

先选了“最棒”的 IdP，开发一半发现不能迁移历史用户，还得全员重置密码。要么迁移体验灾难，要么评委再开。

解决：第一筛选项就看迁移能力。

误区3：过度相信演示#

供应商演示都是完美流程。干净数据库、零边角例外。你的生产环境用户字段有 emoji、合并过账号、还有已注销未清的会话。

解决：让对方用你自己的数据搞个 PoC（概念验证）。导入一千用户，完整跑一遍流程。

误区4：少了关键人员参与评估#

只有平台组评估会选技术最干净的。只有产品会选集成最容易的。只有安全组会选合规最多的。

解决：评估团队应涵盖平台、产品、安全。各自对 P1、P2 担责。

误区5：忘了有一天你会迁出#

供应商锁定很现实。专有 SDK、自定义 API、非标 token 格式会直接增加以后迁出的成本。

解决：优先标准协议（OIDC、OAuth2、SCIM）的 IdP。将来迁移能少踩坑。

FAQ#

IdP 评估一般要多久？#

如需完整评估和概念验证（PoC），通常 4-8 周。赶工往往踩第二个坑，也就是忽略迁移。预算安排：需求梳理 2 周、厂商品评 + PoC 2-3 周、利益相关人对齐 1-2 周。

我们该不该自己造认证系统？#

阶段不同答案不同。用户不到一万且没企业客户，用现成开源库即可。只要用上 SSO、多租户、MFA 和合规材料，自研维护成本就远高于 IdP 费用。见过团队常年养 2-3 个全职工程师手写认证，年成本 30-50 万美元起。

CIAM 和工作流 IAM 有啥区别？#

CIAM（客户身份管理）面向产品终端用户——注册、登录、个人中心。工作流 IAM 是你公司员工进内部工具用的（公司用 Okta 登录 Slack 等等）。两者采购逻辑和评估思路都不同。这份指南关注 CIAM。

开源 IdP 和专有 IdP 有啥利弊？#

开源 IdP 透明度高（能看代码）、可迁移性强（有需要可自托管）、有社区贡献。专有 IdP 通常 UI 更美观、SaaS 服务更管理。核心问题不是“开源还是闭源”，而是“我万一要迁能出得去吗”。开源的一般有标准数据/接口，换家厂商容易很多。

AI agent 认证啥时该升为 P1？#

如果你马上就要做 AI 功能，且覆盖读写用户数据（copilot、自动流程、AI 助理），直接按 P1 要求。如果 AI 功能在 6-12 个月内上线，放 P3 但建议权重加大。如果暂时拍不到 AI，P4 即可，半年后再复盘。

供应商定价各有套路，我们怎么比较？#

绝大多数按 MAU（每月活跃用户）定价。但“活跃”的定义不同——有的算有登录就计，有的按去重，有的 M2M 另计。务必让供应商报你自己的场景：X 用户、Y 个组织、Z 条 M2M 连接和日常流量，然后算实际总价不要只看单价。

总结#

选型 IdP 是基础设施决策，不是功能对比。你押注的是一个系统，承载所有用户的首个操作、API 的每次权限检查和合规团队全部的审计分析。

上一整套实战评估框架，别只看市场宣传语。按优先级快速淘汰（P1），深入调查 P2、P3（最好 PoC），选出能用很多年而不仅仅是几个季度的方案。

真正做对的那些团队有个共同点：他们把身份管理当成基础设施，而不是“一次发布就忘了”的功能。