企业客户问“支持 SSO 吗”：vibe 项目从单用户到 B2B 团队版的升级实战

先划清边界：这篇讲的是哪一层

站内已经有三篇鉴权相关的指南，读之前先把它们和这篇的关系摆清楚，免得你读串了。《鉴权落地实战》（slug：vibe-project-auth-login-permissions-guide）讲的是单个应用里"人怎么登录"——session、JWT、OAuth 回调，是单体视角；《RBAC 权限指南》（slug：vibe-project-rbac-permissions-guide）讲的是同一个租户里面人与角色的关系——谁是管理员、谁只能看；《多租户隔离指南》（slug：vibe-project-multitenancy-isolation-guide）讲的是租户之间的数据隔离——A 公司的数据绝不能漏到 B 公司。而这一篇讲的是这三层之上的东西：身份联邦（federation）与组织建模——"这个人到底是谁"这个问题，不再由你回答，而是由客户公司的 IdP（Okta、Entra ID、Google Workspace）回答；以及"一群人以什么结构用你的产品"这个问题，要从"一堆散装用户"升级成"组织 → 团队 → 成员"的三级结构。简单说：前三篇管的是"你应用内部的门和钥匙"，这篇管的是"整栋楼的门禁系统是谁发的卡、楼里有哪些公司、每家公司有哪些部门"。四篇互链，不重复。

企业客户为什么执念于 SSO：安全问卷的 5 个必答项

个人版跑通、刚有收入，第一个企业客户的采购流程里一定会出现一份安全问卷（security questionnaire），短则 30 题，长则 200 题。不管多长，关于身份认证的必答项永远是这 5 个：1）是否支持 SAML 2.0 / OIDC 单点登录；2）是否支持 SCIM 自动开通/停用账号；3）是否有完整的审计日志（谁、何时、做了什么）；4）离职员工的账号多久能失效；5）是否支持强制 MFA / 与客户现有 MFA 策略联动。答不上来，问卷直接挂，销售连报价的机会都没有。

为什么企业这么执念？不是跟风。站在 IT 管理员的视角想：公司 500 人，每人平均用 40 个 SaaS，如果每个 SaaS 都要单独设密码，就是 500 个"密码写在小本本上"的风险点，外加员工离职时 40 个系统逐个删账号的人肉流程。SSO 把这 40 个登录入口收敛到 1 个：员工只记公司账号的密码（外加 MFA），离职时 IT 在 IdP 里点一下"停用"，所有 SaaS 的访问理论上同时失效。SSO 对企业不是"登录更方便"，是"离职审计"和"合规"的刚需。理解了这一层，你就明白为什么下面这些翻车都发生在"以为接了登录就是 SSO"的地方。

翻车现场：把"Google 一键登录"写成"支持 SSO"。这是 vibe 项目最常见的死法：登录页有个"使用 Google 登录"按钮，定价页赫然写着"SSO：支持"。企业客户的 IT 一看就知道这是两回事：Google 一键登录是社交登录（social login）——认证方是 Google 的公共账号体系，任何人有 Gmail 就能进，你的产品根本区分不出"这是我们公司的员工"还是"路人"；而企业要的 SSO 是身份联邦——认证方是"客户公司自己的 IdP"，只有该公司目录里的人能进，而且进来的人自带"我是哪个部门、什么职级"的属性。把前者当后者卖，轻则在安全问卷上被当场揭穿丢单，重则签了合同后被客户法务认定为虚假陈述。记住一句话：能区分"公司内外"的，才叫 SSO；不分内外谁都能点的，那叫社交登录。

OIDC vs SAML：先做决策，再写代码

SSO 有两个主流协议，选错的代价是重写。先给结论，再给决策表：

维度	OIDC（OpenID Connect）	SAML 2.0
本质	OAuth 2.0 之上的身份层，JSON + JWT	XML 断言的老牌企业标准
谁在用	Google Workspace、新兴 SaaS、开发者友好型 IdP	Okta、Entra ID、传统大企业 IT
接入成本	低：标准库成熟，code + PKCE 流程直白	高：XML 签名、元数据交换、证书轮换都是坑
企业客户覆盖	中小企业、科技公司为主	大企业、金融/政府采购的硬性要求
一句话判断	"现代、好接"	"老派、但大单认它"

决策规则（直接抄）：

1. 先做 OIDC，再做 SAML。OIDC 一周能跑通，SAML 光是和客户 IT 联调元数据就能耗掉两周。第一批企业客户里多数用 Google Workspace 或 Okta（Okta 两边都支持），OIDC 先顶上，把"支持 SSO"变成事实，再用 SAML 去啃剩下要走传统采购的大单。

2. SAML 的启动阈值：单个客户年续费 ≥ 你 2 周人力成本 × 3。量化一下：假设你一周的机会成本是 5000 元，SAML 接入、联调、首年维护约 2 周人力，约 1 万元，那么只有年付费 3 万以上的客户才值得单独为它开 SAML。低于这个数的，让客户用 OIDC（Okta、Entra ID 都支持 OIDC），或者把 SAML 打包进 Enterprise 档、用价格筛掉小客户。这是血泪换来的公式：很多 solo 开发者为一个月付 200 元的"大公司试用客户"手搓 SAML，最后客户没转正，代码烂在仓库里。

3. Auth0 / WorkOS / 自建三选一：

WorkOS：B2B SaaS 的"SSO 外包"首选。它干的就是"把几十种 IdP 的 quirks 抹平"这一件事：你接一套 API，后面是 Okta、Entra ID、Google 还是客户自建的 ADFS，WorkOS 替你翻译。对 solo 团队这是最划算的：按连接收费，但省掉的是你和企业 IT 来回发邮件调元数据的几十个小时。判断标准：如果你预计第一年 SSO 客户不到 10 家，托管方案的账一定划算。

Auth0：功能最全，但定价和复杂度都是企业级的。适合"已经确定走 PLG + Enterprise 双轨、且有专人看身份这块"的团队。对一人团队，它的管理后台学习曲线本身就是一个坑。

自建：只有一种情况值得——你的产品本身就是身份/安全赛道的，SSO 是你的核心能力展示。否则，自建 SAML 的 XML 签名验证、证书过期轮换、IdP 元数据漂移，每一个都是半夜被叫醒的 on-call。用成熟库做 OIDC 是可以的，SAML 自建请三思。

一句话总结：第一年用托管方案把 OIDC 跑通，把省下的时间拿去签单；等 SSO 客户超过 10 家、SAML 需求真实出现时，再评估自建或换更重的平台。身份这层，出问题是"全站所有企业客户同时掉线"级别的事故，不值得为省一点托管费赌上自己的睡眠。

组织数据模型：User ≠ Member，这是第一道分水岭

单用户时代的 vibe 项目，数据模型通常是 User 一张表打天下：邮箱、密码哈希、订阅状态全塞在一起。第一个企业客户进来，第一反应往往是给 User 加个 orgId 字段——这就是未来两年所有权限 bug 的源头。为什么？因为"人"和"人在组织里的身份"是两个东西：同一个人可以是 A 公司的管理员、同时是 B 公司的普通成员；他在 A 公司离职了，他这个"人"不该被删掉，删掉的是他在 A 公司的"席位"。一张表硬塞，三个月后你会发现自己在写 WHERE orgId = ? AND (role = 'admin' OR isSuperAdmin) 这种屎山。

正确的建模是三级：Organization（组织）→ Team（团队）→ OrganizationMember（成员席位），外加独立的 User（自然人）。下面是可直接抄的 Prisma schema：

model Organization {
  id          String   @id @default(cuid())
  name        String
  slug        String   @unique
  plan        String   @default("team")
  ssoEnforced Boolean  @default(false) // 全员强制走 SSO，密码登录直接关掉
  members     OrganizationMember[]
  teams       Team[]
  ssoConnections SsoConnection[]
  invitations Invitation[]
  createdAt   DateTime @default(now())
}

model User {
  id           String   @id @default(cuid())
  email        String   @unique
  name         String?
  passwordHash String?  // 纯 SSO 用户没有密码，允许为空
  memberships  OrganizationMember[]
  createdAt    DateTime @default(now())
}

model OrganizationMember {
  id       String       @id @default(cuid())
  orgId    String
  org      Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)
  userId   String
  user     User         @relation(fields: [userId], references: [id], onDelete: Cascade)
  role     MemberRole   @default(MEMBER)
  status   MemberStatus @default(ACTIVE)
  joinedAt DateTime     @default(now())
  @@unique([orgId, userId])
}

enum MemberRole { OWNER ADMIN MEMBER }
enum MemberStatus { ACTIVE SUSPENDED }

model Team {
  id     String @id @default(cuid())
  orgId  String
  org    Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)
  name   String
  slug   String
  teamMembers TeamMember[]
  @@unique([orgId, slug]) // slug 只在组织内唯一，不同公司可以重名
}

model TeamMember {
  id       String @id @default(cuid())
  teamId   String
  team     Team   @relation(fields: [teamId], references: [id], onDelete: Cascade)
  memberId String // 注意：挂在席位上，不是 User 上
  member   OrganizationMember @relation(fields: [memberId], references: [id], onDelete: Cascade)
  @@unique([teamId, memberId])
}

model SsoConnection {
  id       String  @id @default(cuid())
  orgId    String
  org      Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)
  protocol SsoProtocol // OIDC | SAML
  domains  String[]    // 域名认领：acme.com 的邮箱自动路由到这个 org
  config   Json        // issuer/clientId 或 IdP 元数据，secret 字段加密存储
  createdAt DateTime @default(now())
}

model Invitation {
  id        String @id @default(cuid())
  orgId     String
  email     String
  role      MemberRole @default(MEMBER)
  token     String     @unique
  status    InviteStatus @default(PENDING)
  expiresAt DateTime
}
enum InviteStatus { PENDING ACCEPTED EXPIRED REVOKED }

model AuditLog {
  id      String @id @default(cuid())
  orgId   String
  actorId String   // 操作人 userId
  action  String   // member.invited / member.removed / sso.enabled ...
  target  String?  // 被操作对象
  ip      String?
  createdAt DateTime @default(now())
  // 无更新、无删除：只追加
}

三条铁律，对着上面的 schema 理解：

铁律 1：鉴权只看 Member，不看 User。所有"能不能看这个数据"的判断，输入都是 (orgId, userId) → OrganizationMember.role/status。User 表只回答"你是谁"，Member 表才回答"你在这里能干什么"。把 role 放在 User 表上，是单用户时代留下的最大技术债。

铁律 2：TeamMember 挂在席位（Member）上，不是 User 上。新成员加入团队，走的是"先有席位、再进团队"：邀请接受 → 建 OrganizationMember → 再建 TeamMember。反过来，成员被移出组织时，级联删掉他的 TeamMember 和席位，但 User 行保留——他可能还是别的组织的成员。

铁律 3：SSO 配置挂在 org 上，按租户隔离。SsoConnection.orgId 决定了"这份 IdP 配置只对这个组织生效"。A 公司的 Okta 配置永远不可能被 B 公司的登录流程读到——这是多租户隔离在身份层的落地，和《多租户隔离指南》的数据行级隔离是同一思想的不同切面。

/media/content-media/a56f3ccd-38fe-490f-a5d3-6edb6bc228d5/2026/10/d657d7fe-fcd1-4505-ae77-6d4a3e9f0490.png

org / team / member 三级数据模型 ER 图：User 只存自然人身份，权限只看 OrganizationMember 的 role/status；TeamMember 挂在席位而非 User 上；SsoConnection 与 Invitation 都挂在 org 下按租户隔离；AuditLog 只追加不删改。图中关系与本节 Prisma schema 一一对应。

邀请状态机（Invitation.lifecycle）：PENDING → ACCEPTED（用户点邮件链接、完成认证）或 PENDING → EXPIRED（7 天未点）或 → REVOKED（管理员撤回）。接受邀请的那一刻才创建 OrganizationMember 行——不要在"发出邀请"时就建席位，否则"发出 100 封邀请、只回来 10 个人"会让你的成员计数和账单逻辑全乱掉。计费（按席位收费时）只数 status=ACTIVE 的席位，这是后面定价一节的基础。

接入实战：SP 发起的登录长什么样

不管 OIDC 还是 SAML，企业 SSO 登录都是 SP-initiated（由你的应用发起）：用户在你的登录页点"企业账号登录"，你把他送到客户 IdP，他在那边认证完，IdP 把他送回来。IdP-initiated（从 Okta 面板点图标直接进来）理论上也存在，但第一次联调请只做 SP-initiated——IdP-initiated 的 RelayState 校验是 CSRF 重灾区。

/media/content-media/a56f3ccd-38fe-490f-a5d3-6edb6bc228d5/2026/10/45e85577-6b01-429d-a1d7-4b6dcce6f726.png

OIDC / SAML 登录流程时序图：用户 → 你的应用（SP）→ 企业 IdP 八步往返。蓝色为 OIDC 路径，紫色为 SAML 路径，绿色为两协议相同步骤。核心差异：OIDC 是"code 再换 token"（JWT + JWKS 验签）；SAML 是"断言一次到位"（XML + IdP 证书验签）。图中每一步与本节文字描述对应。

OIDC 接入（推荐先做）：标准 Authorization Code + PKCE 流程。用 openid-client 这类库，别自己拼 URL：

// 伪代码：发起登录（第 2 步）
const authUrl = client.authorizationUrl({
  scope: "openid profile email",
  code_challenge: pkce.challenge,   // PKCE：防 code 拦截
  code_challenge_method: "S256",
  state: randomBytes(16),           // 存 session，防 CSRF
  nonce: randomBytes(16),           // 防重放，写进 id_token 校验
});
// 302 跳转到 IdP

// 回调处理（第 5-7 步）
const tokenSet = await client.callback(redirectUri, params, { state, nonce });
const claims = tokenSet.claims(); // sub（IdP 内的唯一 ID）、email、name
// 验签：库自动用 IdP 的 JWKS 校验 id_token 签名，你只需确认 issuer/audience

SAML 接入（啃大单时再做）：SP-initiated + HTTP-POST binding 是联调成功率最高的组合。三个坑提前说：1）元数据交换：你给客户的 SP 元数据（entityID、ACS URL、证书） vs 客户给你的 IdP 元数据（SSO URL、X.509 证书），任何一边手改一个字符就全崩——做法是两边都贴 URL 自动拉取，不要复制粘贴 XML；2）证书轮换：IdP 证书通常 1-3 年过期，过期前不断连的唯一办法是"提前 30 天监控过期时间 + 到期自动拉新元数据"，把这条写进 checklist；3）NameID 格式：和客户 IT 第一句就要对齐——用 emailAddress 还是 persistent？选错会导致同一个人每次登录生成不同的 sub，账号越用越多。

两边验签的本质是一样的：你信任的不是"用户说自己是谁"，而是"IdP 签名说他是谁"。OIDC 用 IdP 的 JWKS 公钥验 id_token；SAML 用 IdP 元数据里的 X.509 证书验 Response/Assertion 签名。任何"跳过验签先跑通"的临时方案，都是在给中间人攻击留门——联调时图省事关掉验签，上线前必须打开，没有例外。

JIT provisioning：第一次登录就自动建好一切

企业 IT 最烦的场景：500 个员工，难道要管理员一个个点邀请？JIT（Just-In-Time）provisioning 就是答案：用户第一次用 SSO 登录成功的那一刻，你的应用自动完成"建 User（如果不存在）→ 建 OrganizationMember 席位 → 分配默认角色 → 进默认团队"全套动作，零人工干预。流程：

1. 找组织：用 email 的域名在 SsoConnection.domains 里匹配（domain claim，见下节），或用登录页用户选择的组织。匹配不到 → 拒绝登录并提示"你的域名未认领"，不要自动建一个新组织——那是影子 IT 的温床。

2. 找人或建人：按 email 查 User，没有就建（passwordHash 留空，name 取 IdP 断言里的 displayName）。

3. 建席位：按 (orgId, userId) 查 OrganizationMember，没有就建，role 取默认值。默认值策略是门学问：默认给 MEMBER，第一个进组织的人给 OWNER。为什么？JIT 建席位时你不知道这个人是 CEO 还是实习生，给 MEMBER 最安全；而"第一个人"通常是和你对接的 IT 管理员，给 OWNER 让他能进后台配东西。把"第一个 JIT 用户自动升为 OWNER"的规则写死，省掉无数"我们管理员进不去后台"的工单。

4. 角色映射（可选但建议）：如果客户 IdP 的断言里带了 groups（比如 "Engineering-Managers"），建一张映射表 IdP group → MemberRole，JIT 时自动落角色。这一步是 SCIM-lite，80% 的"自动分配角色"需求到这里就够了，不必上全套 SCIM。

账号合并：SSO 登录撞上已有的密码账号怎么办？这是上线第一周必遇的工单。规则按"邮箱"做唯一锚点：1）SSO 断言的 email 和已存在的 User.email 相同 → 直接绑定到同一个 User，不建新账号（前提是该 email 的域名已被该 org 认领，防止冒名）；2）用户之前用密码注册、现在走 SSO → 保留密码（别删），但如果该 org 开了 ssoEnforced，密码登录对该组织直接拒绝——"并存但 SSO 优先"；3）最危险的反向操作：永远不要因为 SSO 登录就覆盖或清空用户原来的密码哈希，万一客户 IdP 故障需要应急切回密码登录，你删掉的哈希就是删掉的逃生通道。

domain claim：谁证明"这个域名是你们公司的"

SsoConnection.domains = ["acme.com"] 听起来简单，但"声称拥有域名"必须验证，否则攻击者注册一个 org、声称 gmail.com，就能劫持所有 Gmail 用户的路由。标准做法二选一：1）DNS TXT 记录验证（推荐）：让客户 IT 在 _vibefix-challenge.acme.com 加一条 TXT，值为你生成的随机 token，你的应用定时查询验证——和域名所有权验证一个逻辑；2）邮箱验证回环：给 admin@acme.com 发验证链接。DNS 方式更可靠，因为能发 admin 邮箱的人不一定管得了 DNS，能管 DNS 的一定是域名主人。

域名认领通过后，登录路由逻辑是：用户输入邮箱 li@acme.com → 域名命中 org → 检查该 org 的 SsoConnection → 直接 302 到对应 IdP，用户连"选组织"这一步都省了。这就是 Notion、Figma 登录页"输入公司邮箱自动跳转"的体验来源。注意边界：一个域名同时只能被一个 org 认领（domains 全局唯一约束），子公司场景（acme.com + acme.co.jp）用多个 SsoConnection 行解决，不要在一个行里塞两个公司的域名。

成员移除后，会话必须立即失效

回到开篇安全问卷第 4 题："离职员工的账号多久能失效？"标准答案是"即时"，而很多 vibe 项目的真实答案是"等他的 JWT 过期（比如 7 天后）"。这中间的窗口期，就是离职员工还能读公司数据的时间。正确做法分三层：

1. 数据层：管理员点"移除成员" → OrganizationMember.status = SUSPENDED（不要物理删除，审计要留痕）。

2. 网关层：每次请求鉴权时，除了验 JWT 签名，再查一次该 (orgId, userId) 的席位状态。嫌每次查库慢？用 Redis 缓一个 60 秒 TTL 的"席位状态"，移除时主动删缓存——失效延迟从"JWT 过期时间"降到"60 秒"，对问卷来说这就是"即时"。

3. IdP 联动层（进阶）：如果做了 SCIM，客户在 Okta 里停用员工 → SCIM 的 PATCH /Users/:id {active: false} 打到你 → 自动走上面的 1、2 步。这才是"IT 点一下，所有 SaaS 同时失效"的完整闭环。

还有一个常被漏掉的：ssoEnforced 打开后，该组织所有密码登录入口要真正关掉，不只是前端隐藏按钮——后端登录接口按 orgId 拒绝密码凭证。安全问卷一定会问"SSO 启用后是否还能用密码绕过"，答案必须是"不能"，而且你要能拿出后端代码证明。

多组织用户的切换器：一个人是 A 公司管理员、同时是 B 公司成员时，登录后第一件事是"选进哪个组织"。做法：session 里存 activeOrgId，顶栏放组织切换器，切换组织 = 换 activeOrgId + 重新拉该组织的席位权限（不要让用户重新登录）。所有 API 按 activeOrgId 做数据隔离——这是《多租户隔离指南》的行级隔离在会话层的延续。URL 里带 org slug（/acme/dashboard）比纯靠 session 更利于分享链接，但要做好"slug 变了老链接 301"的兜底。

SCIM：什么时候值得做，什么时候别碰

SCIM（System for Cross-domain Identity Management）是"IdP 主动调你的 API 同步人员变动"的协议：入职自动建账号、转岗自动换组、离职自动停用。听起来很美，成本也很真实：要实现 /scim/v2/Users 和 /Groups 的 CRUD + 分页 + 过滤，还要和 Okta、Entra ID 逐个联调。决策线很清晰：员工规模 > 200 人的客户要求 SCIM 才做；以下只给 JIT + 手动邀请。200 人是经验阈值：低于这个数，IT 手动在后台点邀请的成本，远低于你开发联调 SCIM 的成本。以及，SCIM 永远做在"SSO 已经稳定跑了三个月"之后——身份联邦没跑顺就上自动同步，等于给还没调准的枪装上连发扳机。

企业试用转正 checklist：签约前的 12 项技术验收

下面这份清单是给"客户说要试用、转正前 IT 要验收"准备的。把它做成你后台的一个页面，客户 IT 一项项打勾——这本身就是专业度的证明：

身份与登录（1-5）：1）SP-initiated 登录端到端跑通（录屏留存）；2）IdP 元数据/ OIDC discovery 可定时自动刷新，证书过期前 30 天告警；3）ssoEnforced 开启后密码登录被后端拒绝（附测试用例）；4）登出是"真登出"：清掉你应用的 session，同时可配置跳回 IdP 登出页（SLO 可选）；5）MFA 由 IdP 侧强制，你的应用不降级、不绕过。

组织与成员（6-9）：6）JIT 建席位 + 第一个用户自动 OWNER；7）邀请链接 7 天过期、撤回即时失效；8）成员移除后 60 秒内会话失效（附测试方法）；9）审计日志可按组织导出（CSV），保留 ≥ 1 年，成员移除/角色变更/SSO 配置变更全记录。

运维与应急（10-12）：10）客户 IdP 故障时的应急通道：保留一个"break-glass"管理员账号（硬件密钥 + 异地保管），写进合同附件；11）状态页公开身份服务可用性，事故 15 分钟内通知客户对接人；12）数据删除：合同终止后 30 天内删除该组织全部数据，备份滚动覆盖，给出书面证明流程。

安全问卷应答模板（贴一段就能用的话术）："贵司员工通过贵司 IdP（Okta / Entra ID / Google Workspace，支持 OIDC 与 SAML 2.0）认证后，经签名的断言登录本产品；本产品不存储贵司员工密码。员工离职时，贵司在 IdP 停用账号后 60 秒内，本产品内该成员所有会话失效（支持 SCIM 自动同步，200 人以上规模建议启用）。所有成员变更、角色变更、SSO 配置变更均写入不可篡改的组织级审计日志，支持导出，保留 1 年。"——把这段话原样放进问卷的"身份认证"大题，IT 一看就知道你是内行。

第一次联调：发给客户 IT 的对接包

SSO 联调最大的时间黑洞不是写代码，是和客户 IT 在邮件里来回对"你要什么、我给你什么"。第一次对接就把下面这个"对接包"一次发全，能把两周的邮件拉锯压缩到三天：

你要发给客户的（SP 侧信息）：1）SP entityID（建议用 https://yourapp.com/sso/metadata/<orgSlug> 这种带组织标识的格式，一个组织一份，省得以后并购场景扯皮）；2）ACS URL（收断言的地址，SAML 是 POST 过去的那个）；3）你的 SP 签名证书（如果你要求 IdP 验你的 AuthnRequest 签名——建议要，开了之后能防请求伪造）；4）需要 IdP 回传的属性清单：email（必填）、displayName、groups（可选，用于角色映射）。

你要问客户要的（IdP 侧信息）：1）IdP 元数据 URL（优先要 URL 不要 XML 文件，URL 能自动刷新）；2）NameID 格式确认（emailAddress 还是 persistent，前面说过，错了会账号分裂）；3）groups / 部门属性的 claim 名字（每家 IdP 叫法不一样，Okta 叫 groups，Entra ID 可能是 http://schemas.microsoft.com/ws/2008/06/identity/claims/groups 这种长串，不问清楚就等着猜）；4）测试账号：至少两个——一个普通员工、一个管理员，外加"模拟离职"时配合停用的那一个。

联调顺序（别跳步）：先在你自己的测试租户里用客户的测试 IdP 应用跑通（Okta/Entra ID 都支持建一个"测试应用"不影响生产目录）；再切到客户的生产 IdP 做冒烟；最后才开 ssoEnforced。见过太多人第一步就直接连客户生产 IdP，一个配置错导致客户全公司登录页报错——那封道歉邮件的成本，比你多等两天高得多。

SSO 上线翻车 Top 5：都是真事

1. 证书半夜过期，全站企业客户掉线。IdP 证书 2 年有效期，过期那天凌晨 3 点，所有 SAML 登录开始报验签失败。解法：元数据 URL 自动刷新 + 证书过期前 30/7/1 天三级告警，写进值班手册。

2. 时钟漂移 5 分钟，断言全被拒。SAML 断言和 OIDC id_token 都有 NotBefore/exp 时间窗口，服务器时钟和 IdP 差 5 分钟以上就全军覆没。解法：生产机开 NTP 是基线，验签时给 300 秒的时钟宽容度（clock skew tolerance），这是标准做法不是偷懒。

3. NameID 选错，同一个人变出三个账号。客户 IT 给了 persistent 格式的 NameID，你按 email 建账号，结果 NameID 是个不透明 ID，同一个邮箱每次登录 sub 还不一样——账号越用越多。解法：对接第一天就确认 NameID 格式，并且永远以 email 为账号合并锚点，sub 只做"同一个人"的辅助判断。

4. 断言里没有 email，白忙一场。有些 IdP 默认不回传 email（隐私策略），你的 JIT 流程第一步就卡死。解法：对接包里把"email 必填"写死，联调第一天就拿测试账号验证断言内容，别等到上线前一天。

5. 开了 ssoEnforced，创始人自己被锁外面。全员强制 SSO 后，创始人的个人密码账号也登不进了，而客户 IdP 那边还没把他加进目录。解法：ssoEnforced 只对"该组织的普通成员"生效，OWNER 角色永远保留密码/硬件密钥登录——以及前面说的 break-glass 账号，两个逃生通道缺一不可。

solo 团队的 30 天落地路线图

道理都懂，排期怎么排？给一人团队一份现实的 30 天计划：第 1 周：数据模型迁移——按上面的 Prisma schema 建 Organization / OrganizationMember / Team / SsoConnection，把现有 User 表的数据"认领"进默认组织（每个老用户自动成为自己个人组织的 OWNER，老功能零感知）；第 2 周：接托管方案的 OIDC，打通 SP-initiated 登录 + JIT + 账号合并，后台做出"启用 SSO / 强制 SSO"开关；第 3 周：补齐审计日志导出、成员移除即时失效、邀请状态机，拿第一个种子企业客户做联调（用上面的对接包）；第 4 周：定价页加上 Enterprise 档（SSO + 审计导出 + 专属支持），安全问卷应答模板入库。SAML 和 SCIM 不在前 30 天——它们是"有真实客户买单"之后才开的支线。

定价建议：SSO 是付费墙，不是标配

最后谈钱。SSO 一定要收费，而且要贵。行业惯例：SSO 是 Team/Enterprise 档的专属功能，或者按连接收年费的 add-on。为什么？1）成本真实：托管方案按连接收费、联调吃人力，免费送就是赔本；2）信号价值：愿意为 SSO 付费的客户，恰恰是"有 IT、有预算、续费率高"的优质客户，用价格把他们筛出来；3）锚定效应：把"SSO + SCIM + 审计日志导出"打包成 Enterprise 档，比单卖三个功能 perceived value 高得多。

给 solo 团队的定价公式：SSO add-on 年费 = 你为单个客户做 SSO 联调+首年维护的人力成本 × 2。按前面的估算（首年约 1 万元人力），add-on 定价 2 万/年起是合理的——客户对比的是"自己 IT 团队折腾开源方案"的人力成本，你的报价只要低于他们两周人力，就是划算的。以及，按席位（ACTIVE 成员数）收费和 SSO 是天然搭档：SSO 让"全员接入"变得零摩擦，席位自然涨上去。把"成员数"做成用量维度，SSO 就是你扩席位的发动机。

收尾说句判断：SSO 项目最大的坑从来不是协议本身，是"用单用户的脑子做多组织的事"。User 和 Member 分家、SSO 配置挂在 org 上、移除即失效——这三条想通了，OIDC 还是 SAML、WorkOS 还是自建，都只是工程细节。反过来，这三条没想通，协议接得再标准，上线第一周就会被客户 IT 的第一个问题问住："离职的人，多久进不来？"——答不上来，单就黄了。而答得上来的团队，拿到的不只是一单——是整套 B2B 的入场券。