身份提供方（Okta、Azure AD、Google Workspace、JumpCloud 等）刚改完配置，ChatGPT Enterprise SSO 就挂了——跳转链路看着没问题，SAML POST 打到 OpenAI 后被退回，提示”SAML response invalid”或”user not found”。最短的修法是：从 IdP 重新导出 metadata、上传到 platform.openai.com 的 Enterprise 后台，然后核对 NameID 和邮箱 claim 是否对得上。极少是 OpenAI 这边的问题——先从 IdP 审计日志看起。
常见原因
1. SAML 签名证书轮换了，OpenAI 还在用旧的
IdP 的签名证书 1-2 年会轮换一次。如果 IdP 那边换了证书但新 metadata XML 没重新传给 OpenAI，所有 SAML response 的签名验证都会失败。
怎么判断：Okta / Azure 后台 → Application → SAML signing certificate，看 thumbprint 和”valid from”日期。比上次传给 OpenAI 的更新就是这个原因。
2. NameID 格式改了（email 改成 persistent 或反过来）
OpenAI Enterprise 要求 NameID 是用户的邮箱（urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress）。如果 IdP 管理员为了配合别的 SaaS 改成 persistent 或 unspecified，OpenAI 就识别不出用户。
怎么判断：用 SAML-tracer 浏览器插件抓 SAML response，看 <NameID Format="...">。不是 emailAddress 就会挂。
3. 邮箱 attribute claim 改名或被删了
有的 IdP 用 email，有的用 EmailAddress，有的用 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress。OpenAI 初始接入时绑定了一个特定的属性名，IdP 管理员一改名映射就断了。
怎么判断：看 SAML response 里的 <AttributeStatement>，里面有没有 OpenAI 配置时指定的那个确切属性名。
4. SCIM 还没同步过来，用户没被推过去
开了 SCIM 的 ChatGPT Enterprise 只让预先开通过的用户登。如果 IdP 那边新加了人但 SCIM 还没同步（或者被暂停了），登录会报”user not authorized”。
怎么判断：platform.openai.com → Enterprise admin → Users，看用户在不在列表里。不在就说明 SCIM 还没推过来。
5. IdP group claim 和 OpenAI 允许的组对不上
有的 Enterprise 租户按 group claim 限制访问（比如只允许 chatgpt-users 组）。如果 IdP 管理员把组改名了或把用户从组里移出去了，SAML response 本身能签下来，但 OpenAI 这边鉴权过不了。
怎么判断：SAML response 里应该包含一个 groups 或 MemberOf claim，看里面的值是不是预期的。
开始前
- 先确认这是 Enterprise SSO 的问题，不是个人 Google/Apple SSO——两套流程完全不同。
- 提前准备好 IdP 管理员权限（Okta admin、Azure portal、Google admin console），大多数修法都得用到。
- 装一个 SAML-tracer 或 Chrome 的”SAML Chrome Panel”，用来抓真实的 SAML response。
需要收集的信息
- OpenAI 端的完整报错文案（“SAML response invalid”、“user not found”、“no matching account”）。
- IdP 类型和版本（Okta、Azure AD、Google Workspace、JumpCloud、OneLogin）。
- 最近一次 IdP 端改动的日期和内容（证书轮换、metadata 改了、属性映射改了、SCIM 暂停）。
- 一份抓到的 SAML response XML（脱敏过、去掉签名值）。
- OpenAI Enterprise workspace ID 和管理员邮箱。
- IdP 审计日志里失败登录的对应条目。
- 是不是还有用户能登成功（能区分是个别用户问题还是租户级问题）。
一步一步修复
Step 1：先看影响面有多大
在 IdP 后台看 OpenAI 应用的审计 / 系统日志。所有人都登不了就是 metadata / 证书 / claim 层的问题；只有部分用户登不了就重点查 SCIM 同步或者组成员关系。
Step 2：把 IdP metadata 重传一遍
绝大多数情况从这一步就能解决。从 IdP 导出：
Okta: Applications → ChatGPT Enterprise → Sign On → View Setup Instructions → IdP metadata URL
Azure AD: Enterprise applications → ChatGPT → SAML → App Federation Metadata Url
Google Workspace: Apps → Web and mobile apps → ChatGPT → Download metadata然后到 platform.openai.com → Enterprise admin → SSO，上传新 XML（或者直接粘 URL）。OpenAI 会用新证书重新验证签名。
Step 3：核对 claim 映射
OpenAI Enterprise SSO 至少要求：
| OpenAI 字段 | 期望的 SAML 属性 |
|---|---|
| NameID | 用户邮箱，格式 emailAddress |
| 主邮箱 | |
| firstName | 名 |
| lastName | 姓 |
如果 IdP 管理员最近把哪个属性名改了，要么改回原名，要么更新 OpenAI 这边的映射（非自助字段得开工单让 OpenAI 改）。
Step 4：用 SAML-tracer 实地测一遍
开个新窗口装好 SAML-tracer，登一次。看抓到的 response：
1. <Signature> 块存在，且能用新传的证书验过
2. <NameID Format="...emailAddress"> 里是用户邮箱
3. <AttributeStatement> 包含 email/firstName/lastName 这些 claim
4. <Conditions NotBefore/NotOnOrAfter> 覆盖当前时间（避免时钟漂移）哪一步不通过就直接定位到根因，不用瞎猜。
Step 5：SCIM 问题要强制重同步
如果只有特定用户登不上、其他人能登：
- Okta：Provisioning → Force sync，或者把用户移除再重新分配
- Azure AD：Provisioning → Restart provisioning，然后用”On-demand provisioning”测一下这个用户
- Google：用户自动开通有延迟——等 10 分钟，或者在 platform.openai.com 手动建一下
重试登录前先确认用户出现在 platform.openai.com → Enterprise admin → Users 里。
Step 6：联系 OpenAI Enterprise 支持
1-5 步都没解决的话，通过专属 Enterprise Slack 频道或 enterprise-support@openai.com 走优先工单。附上脱敏的 SAML response、IdP 审计日志条目、失败登录的精确时间戳。Enterprise SLA 通常是 4 个工作小时。
怎么验证修好了
- 每个访问层级的测试用户（普通成员、管理员、SCIM 开通用户、组限制用户）都能成功登录。
- SAML-tracer 抓出来的 response 签名干净，所有期望的属性都在。
- platform.openai.com → Enterprise admin → Audit log 里能看到测试登录的成功记录。
- IdP 审计日志里 OpenAI 应用没有警告条目。
- 半小时后用无痕窗口再测一次，排除缓存状态。
长期预防
- 让 IdP 管理员订阅证书过期提醒，至少在轮换前 30 天就准备好新 metadata。
- 把映射到 OpenAI 的 SAML 属性名写进 runbook，别靠记忆。
- 准备一个 staging Enterprise workspace，IdP 端有大改动时先在那边测。
- 在 platform.openai.com 留一个非 SSO 的”应急”本地管理员账号，SSO 挂了还能进去修。
- 每季度做一次 SSO 健康检查——抓一次 SAML response，确认所有期望的 claim 都还在。
容易踩的坑
- metadata 传完了但忘了刷 IdP 端会话——旧 SAML response 还会继续发，直到 IdP 缓存过期。
- 把 Enterprise SSO 和个人 Google SSO 搞混——两套配置完全独立。
- 直接在生产改 claim 没留回滚方案——老配置一定要先导出存好。
- 所有管理员都用 SSO——SSO 一挂，没人能进去修，只能等 OpenAI 介入。
- 以为 SCIM 是实时的——大多数 IdP 是 10-40 分钟一次的定时任务。
常见问答
Q：重传 metadata 会把当前登录的人踢下线吗？ A：不会。已经登录的会话在 token 到期前都还能用（通常 8-24 小时）。只有新发起的登录走新 metadata。
Q：新 metadata 出问题了能回滚吗？ A：前提是你存了旧 XML。上传新的之前一定要先把老的导出来备份。
Q：SAML-tracer 显示 response 已签名，OpenAI 还是说”invalid”，怎么回事？ A：response 签名里的证书 thumbprint 和你传的证书对不上。从 IdP 重新导一次——有时候 metadata URL 返回的证书和实际 SSO endpoint 用的不一样。
Q：每次 IdP 改动都得联系 OpenAI 支持吗？ A：不用。metadata、证书、claim 的常规变更都能在 Enterprise 后台自助完成，只有 schema 级别的映射变更才需要开工单。
Q：SCIM 显示用户已开通，但还是登不上？ A：核对一下 IdP 端的主邮箱和 SCIM 推到 OpenAI 的邮箱是否一致。不一致的话 SCIM 成功了登录还是会”user not found”。