每个 B2B SaaS 都会以同样的方式撞上身份问题：一单生意谈得顺风顺水，客户方的内部支持者对产品爱不释手，然后客户 IT 团队发来一份安全问卷。第三题是*“你们支持 SSO 吗？”*——如果你的回答是“我们有 Sign in with Google”，这单生意就会卡住。不是因为你的认证做得差，而是因为你回答的问题，和企业采购问的那个不是同一个。
第一篇讲清楚了谁的数据归谁。这一篇讲的是谁的身份归谁——以及它背后 2026 年安静的现实：根据 Gartner 2026 年的一项调查，78% 的企业 IT 负责人把 SSO 集成和合规认证视为采用新 SaaS 工具的硬性门槛，而身份管理到位的组织报告的安全事件少了 42%。身份不是一个功能。它是通往企业收入的大门。
三个都叫「登录」的东西
混乱始于词汇。三个不同的系统都被叫做“登录”，而问卷指的只是其中之一：
- 社交登录（“Sign in with Google”）——用消费级账号做认证。方便，但和企业 SSO 完全是两回事：身份归用户所有，客户的 IT 部门什么都管不着。没有任何问卷接受它。
- 你自己的认证体系——由你签发的邮箱/密码或 passkey，会话由你管理。钥匙在你（供应商）手里。这是必需的，但它让客户的 IT 不得不依赖你的策略，而不是他们自己的。
- 企业 SSO + SCIM——客户的员工对着客户自己的身份提供商（Okta、Microsoft Entra ID、Google Workspace、Ping、OneLogin、JumpCloud）认证，账号的开通和注销由客户的目录系统驱动。钥匙在客户 IT 手里。这才是“你们支持 SSO 吗”的意思。
协议：采购现实里的 SAML 2.0 与 OIDC
流程本身很简单，而且两个协议里完全一样：你的应用永远看不到密码。用户被重定向到他们公司的 IdP，在那里完成认证——受 IdP 自己的 MFA 和条件访问策略约束——然后带着一份签名的断言（SAML）或 JWT（OIDC）回来，你的应用用 IdP 公布的密钥验签。
两个协议在其他所有方面都不同：
| SAML 2.0 | OIDC | |
|---|---|---|
| 年代 / 格式 | 2002 年，XML 断言 | 2014 年，基于 OAuth 2.0 的 JSON/JWT |
| 配置方式 | 手工交换 metadata + 证书 | 自动发现 URL + JWKS 密钥轮换 |
| 最佳场景 | 浏览器场景的企业 SSO | SPA、移动端、API、面向开发者的流程 |
| 别扭之处 | XML 解析、双方证书轮换、移动端 | token 存储与 redirect URI 的纪律 |
让开发者意外的是这一点：采购问卷至今仍点名要求 “SAML 2.0 SSO”，尽管 OIDC 在技术上更现代。原因是存量——多年前就配置好的 Entra ID、Okta、ADFS 和 Ping 部署说的是 SAML，写问卷的人写的就是他们自己在跑的东西。2026 年的答案不是二选一：两个都支持。SAML 因为它能赢下企业订单，OIDC 因为新一代 IdP 和你自己的开发者流程更喜欢它。
无论选哪个都要尊重的实现陷阱：SAML 要求小心断言重放和 metadata 篡改（验签、遵守 NotOnOrAfter、固定 IdP 证书）；OIDC 要求严格的 redirect URI 匹配、短寿命 access token 和 nonce 校验。两者在实现正确时都是安全的。“正确”正是几乎没人再手写实现它们的原因——下面会讲。
SCIM：所有人都会忘掉的那一半
SSO 让用户进得来。它对让他们出去只字未提。后一半就是 SCIM（System for Cross-domain Identity Management，跨域身份管理系统），而对 IT 买家来说它不是可选项——它才是真正的重点。
生命周期是三个事件，全部由客户的目录系统驱动：入职者（joiner）获得一个角色正确的账号；转岗者（mover）换团队时角色随之更新；离职者（leaver）被注销——访问权限自动失效，在周五下午六点，不需要给你的团队提一张工单。没有 SCIM，离职处理就是一串邮件加一场祈祷，孤儿账号不断累积——恰恰是事后复盘报告里反复出现的那类账号。这就是为什么每份问卷里“SSO + SCIM”总是成对出现，也是为什么像 Clerk 把 SCIM 推向 GA（2026 年 4 月）这样的厂商动作能成为行业新闻。
自建还是购买：2026 年的市场格局
在六个 IdP 上同时支持 SAML 和 OIDC 和 SCIM，还要按租户配置、配自助管理门户——这是几个月你不会享受维护的协议苦工。市场已经分层，你不必亲自做：
- WorkOS——企业就绪层：SSO、SCIM、目录同步、审计日志，全部以 API 形式提供，按连接数固定计费。和你已有的会话层搭配使用（Better Auth、Clerk 或自研）。是“几天内补齐企业短板”的标准答案。
- Better Auth——自托管的答案：组织、2FA、passkey 和 SSO 插件都在你自己的 Postgres 里，没有按用户数计费的曲线。运维归你；客户的数据留在你的数据库里（见第一篇）。
- Clerk——托管捷径，正在向 B2B 重新定位：打磨过的组件、组织功能，现在还有了 SCIM。上线最快；定价随 MAU 增长。
- PropelAuth——只做 B2B，提供自托管 sidecar（“BYO”），不用迁移平台就能把企业 SSO 挂到现有认证体系上；连接数不限，不按连接收费。
- Auth0——成熟的在位者：协议覆盖最广，按 MAU 计费，越过免费额度后涨价凶猛。
看定价形状比看功能列表更重要：按连接计费（WorkOS、PropelAuth）适合少数大型租户的模式；按 MAU 计费（Auth0、Clerk）跟随消费级增长曲线，可能把一个成功的企业销售季度变成一张意外的账单。无论买哪家，都按你的买家会用的同一张清单检查：两种协议、IdP 覆盖、SCIM、审计日志、自助管理门户——这决定了一天接入和两周邮件拉锯的差别。
配套的控制项
SSO 不替代你的基线，它加入基线。问卷到来之前要配置好的三件事：
- 在策略层面强制执行 MFA——微软的防御数据显示，在被强制执行时，MFA 能阻挡超过 99% 的基于身份的攻击。限定词才是重点：大多数入侵之所以发生，是因为 MFA 只是可选。对高价值租户做成服务端强制，而不是用户偏好。
- 默认无密码——对 2026 年的新项目，“passkey 为主、密码兜底”是出厂默认；彻底移除密码是没人能完成的长跑迁移。
- 按租户的会话策略——access token 15–60 分钟、带 refresh 轮换；会话空闲 30–60 分钟超时、绝对上限 8–24 小时——并且可按租户配置，因为金融和医疗客户会要求在你选的数值上减半。
问卷通关手册
这些文档全都长一个样。它们问：SSO（SAML 2.0？）、SCIM、MFA 强制、审计日志、SOC 2 报告、DPA、数据驻留、静态和传输加密、事件响应流程、子处理方名单。能赢的回答模式是“能，附证据”：信任页面的链接、SOC 2 报告（本系列后面的一扇门）、审计日志导出、DPA 模板。每个“不能”都是一次交易复审；每个“可以，但是——“都是两周延误。
系列的下一站
下一扇门的当前候选：审计日志——把“我们重视安全”和“证明给我看”分开的那一行：该记什么、如何做到防篡改，以及为什么你企业客户的 SOC 团队会在他们法务开口之前先要导出文件。账单安全（webhook 验签、PCI 边界）是另一个有力候选。和之前一样：顺序到时候再定。
动手练习
- 写下你当前的登录面：三种“登录”里你实际提供了哪几种？如果明天收到一份企业问卷，哪些问题你能答“能，附证据”，哪些是诚实的“还不能”？
- 在纸上画出你的应用的 SSO 流程：重定向去哪、谁来验签断言、IdP 的密钥从哪来、密钥轮换时会发生什么？
- 在脑子里追一遍离职场景：你最大客户的一名员工离职了。今天，他对你们产品的访问权限具体通过什么机制失效、要花多久？如果答案涉及“某个人记得去操作”，那就是 SCIM 要填的缺口。