身份提供方（Okta、Microsoft Entra ID、Google Workspace、JumpCloud、OneLogin 等）刚改完配置，ChatGPT Enterprise（或 Business）SSO 就挂了。跳转链路看着没问题，但 SAML POST 打到 OpenAI 后被退回，提示 SAML response invalid、user not found 或 no matching account。
最快的修法（约 80% 的情况都管用）： 从 IdP 重新导出当前的签名证书，然后到 OpenAI 的 Identity & Provisioning 页面 https://chatgpt.com/admin/identity → SSO，把 X.509 证书重新粘进去（或重新上传 metadata）。OpenAI 官方支持文档明确写道：user not found”几乎总是说明你给 OpenAI 的 X.509 证书，和 IdP 返回的 SAML response 里那个对不上”。这基本不是 OpenAI 这边宕机——先看 IdP 审计日志，别盯着 status.openai.com。
后台搬家了。 截至 2026 年 6 月，SSO/SCIM 的控制项在
chatgpt.com/admin/identity（即 Identity & Provisioning 标签页），租户级设置在admin.openai.com的 Global Admin Console 里。老的platform.openai.comSSO 面板，其实是 API Platform 对同一个连接的视图。ChatGPT Enterprise 和 API Platform 每个 IdP 共用一个 SSO 连接，所以改一边、两边都受影响。
你属于哪一类
用报错文案和影响面，直接跳到对应的原因。
| 你看到的现象 | 最可能的原因 | 跳到 |
|---|---|---|
user not found / no matching account，所有人 | X.509 证书对不上（证书轮换了） | 原因 1 |
SAML response invalid，所有人 | 证书过期，或断言被加密了 | 原因 1 / 6 |
| 能登进去但落到错的/空的账号 | NameID 改了（不是 emailAddress） | 原因 2 |
user not found，但只有新用户 | 邮箱属性改名了，或 SCIM 没跟上 | 原因 3 / 4 |
部分用户报 user not authorized | SCIM 没同步，或 group claim 不匹配 | 原因 4 / 5 |
常见原因
1. SAML 签名证书轮换了，OpenAI 还在用旧的
IdP 的签名证书 1-2 年会轮换一次（Entra ID 默认会自动轮换）。如果 IdP 那边换了证书，但新证书 / metadata 没重新粘进 OpenAI，所有 SAML response 的签名验证都会失败。OpenAI 把这种情况报成 user not found 或 SAML response invalid——签名 response 里的证书 thumbprint，和 OpenAI 信任的那张证书对不上了。这是最常见的原因。
怎么判断：Okta / Entra 后台 → 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 把 NameID 改成了 persistent 或 unspecified，OpenAI 就识别不出用户——登录可能”成功”，但落到一个错的或空的账号上。
怎么判断：用 SAML-tracer 插件抓 SAML response，看 <NameID Format="...">。不是 emailAddress 就会出问题。
3. 邮箱 attribute claim 改名或被删了
OpenAI 是靠断言里的 email 属性来认账号的。有的 IdP 发 email，有的发 EmailAddress，有的发 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress。OpenAI 建议只发一个稳定的邮箱（用 UPN 就很合适），这样账号才不会飘。IdP 管理员一旦把这个属性改名，受影响的用户映射就断了。
怎么判断：看 SAML response 里的 <AttributeStatement>——里面是不是正好包含 IdP 接入向导让你发的那个属性名，而且邮箱值只有一个？
4. SCIM 还没同步过来，用户没被推过去
开了 SCIM 目录同步后，ChatGPT Enterprise 只让预先开通过的用户登。如果 IdP 那边新加了人，但 SCIM 还没同步（或者被暂停了），登录会报 user not authorized。
怎么判断：chatgpt.com/admin → Members，看用户在不在列表里。不在就说明 SCIM 还没推过来。SCIM 任务一般是 10-40 分钟一次的定时同步，具体看 IdP。
5. IdP group claim 和 OpenAI 允许的组对不上
有的租户按 group claim 限制访问（比如只允许 chatgpt-users）。如果 IdP 管理员把组改名了，或把用户从组里移出去了，SAML response 本身能签下来，但鉴权这一关过不了。
怎么判断：SAML response 里应该有一个 groups 或 MemberOf claim，看里面的值是不是预期的。
6. 断言现在被加密了
OpenAI 不支持加密的 SAML response 或断言——它解不了密，自然读不到属性。如果 IdP 管理员开了断言加密（有时是租户级的安全默认项），那即便证书是对的，每次登录也都会失败。
怎么判断：在 IdP 的 SAML 应用设置里，确认 response/assertion 加密是关着的。签名要开着，加密要关着。
开始前
- 先确认这是 Enterprise/Business SSO 的问题，不是个人 Google/Apple 登录——两套流程完全不同。
- 提前准备好 IdP 管理员权限（Okta admin、Entra portal、Google admin console），大多数修法都得用到。
- 装一个 SAML-tracer（Firefox）或 “SAML Chrome Panel”，用来抓真实的 SAML response。
- 留一个非 SSO 的应急管理员账号（见”长期预防”），这样 SSO 挂了你还能进
chatgpt.com/admin。
需要收集的信息
- OpenAI 端的完整报错文案（
SAML response invalid、user not found、no matching account、user not authorized）。 - IdP 类型和版本（Okta、Entra ID、Google Workspace、JumpCloud、OneLogin、PingFederate）。
- 最近一次 IdP 端改动的日期和内容（证书轮换、改 metadata、属性改名、加密开关、SCIM 暂停）。
- 一份抓到的 SAML response XML，脱敏过的（去掉签名值和个人信息）。
- OpenAI workspace ID 和一个管理员邮箱。
- IdP 审计日志里失败登录的对应条目。
- 是不是还有用户能登成功（能区分是租户级问题还是个别用户问题）。
一步一步修复
Step 1：先看影响面有多大
在 IdP 后台打开 OpenAI 应用的审计 / 系统日志。如果所有人都登不了，问题在证书 / metadata / claim / 加密这几层（原因 1、2、3、6）；如果只有部分用户登不了，就重点查 SCIM 同步或组成员关系（原因 4、5）。
Step 2：重新导出证书，到 chatgpt.com/admin 重传
绝大多数故障从这一步就能解决。先从 IdP 拿到当前的签名证书 / metadata：
Okta: Applications → ChatGPT → Sign On → SAML Signing Certificates →
Actions → View IdP metadata (或复制 X.509 证书)
Entra ID: Enterprise applications → ChatGPT → Single sign-on →
SAML Certificates → App Federation Metadata Url / Certificate (Base64)
Google: Apps → Web and mobile apps → ChatGPT → Download metadata然后到 OpenAI：chatgpt.com/admin/identity → SSO → 编辑 SAML 连接 → 把 X.509 证书内容粘进去（或填 metadata URL）保存。OpenAI 会用新证书重新验证签名。如果你还没做过，注意：必须先验证至少一个域名（Identity & Provisioning → + Add Domain → 在 DNS 加上那条 TXT 记录），才能启用 SSO。
Step 3：核对 claim 映射
OpenAI Enterprise SSO 至少要求：
| OpenAI 字段 | 期望的 SAML 属性 |
|---|---|
| NameID | 用户邮箱，格式 emailAddress |
| 一个稳定的主邮箱（建议用 UPN） | |
| firstName | 名 |
| lastName | 姓 |
如果 IdP 管理员最近把哪个属性名改了，要么改回原名，要么把 OpenAI 这边的映射改成一致。有些非自助的映射改动仍需要开 OpenAI 工单。
Step 4：用 SAML-tracer 实地测一遍
开个新窗口装好 SAML-tracer，登一次。看抓到的 response：
1. <Signature> 存在，且能用新传的证书验过
2. response/assertion 没被加密（XML 是明文，能直接读）
3. <NameID Format="...emailAddress"> 里是用户邮箱
4. <AttributeStatement> 里只有一个 email，外加 firstName/lastName
5. <Conditions NotBefore="..." NotOnOrAfter="..."> 覆盖当前时间如果第 2 行不通过（正文是 <EncryptedAssertion>），那就是原因 6——把加密关掉。如果第 5 行不通过，就是时钟漂移：两端都对一下 NTP，因为多数验证方只允许 1-2 分钟的误差。
Step 5：SCIM 问题要强制重同步
如果只有特定用户登不上、其他人能登：
- Okta：Provisioning → Force Sync，或者把用户移除再重新分配
- Entra ID：Provisioning → Restart provisioning，再用 Provision on demand 把这个用户跑一遍
- Google：自动开通有延迟——等 10 分钟左右，或者在
chatgpt.com/admin→ Members 里手动建
重试登录前，先确认用户出现在 chatgpt.com/admin → Members 里。
Step 6：联系 OpenAI Enterprise 支持
Step 1-5 都没解决的话，通过专属 Enterprise Slack 频道（或产品内 Help → Contact）走优先工单。附上脱敏的 SAML response、IdP 审计日志条目，以及失败登录的精确时间戳。Enterprise 支持一般在几个工作小时内响应。
怎么确认修好了
- 每个访问层级各取一个测试用户（普通成员、管理员、SCIM 开通用户、组限制用户）都能成功登录。
- SAML-tracer 抓出来的 response 是已签名、未加密的，NameID 等于邮箱，所有期望的属性都在。
chatgpt.com/admin→ Audit log 里能看到测试登录的成功记录。- IdP 审计日志里 OpenAI 应用没有警告条目。
- 半小时后用无痕窗口再测一次，排除缓存状态。
长期预防
- 让 IdP 管理员订阅证书过期提醒，至少在轮换前 30 天就准备好新证书。（Entra ID 的自动轮换是最常见的”无声杀手”。）
- 如果 IdP 支持，就让 OpenAI 指向 App Federation Metadata URL，而不是粘死一张证书，这样证书轮换能被自动接住。
- 把映射到 OpenAI 的 SAML 属性名写进 runbook，别靠记忆。
- 至少留一个非 SSO 的应急本地管理员，能进
chatgpt.com/admin，这样 SSO 挂了还有人能修。 - 每季度做一次 SSO 健康检查：抓一次 SAML response，确认所有期望的 claim 都还在、且没被加密。
容易踩的坑
- 证书粘完了，但 IdP 端旧会话还缓存着——旧 SAML response 会继续发，直到 IdP 缓存过期。
- 在 IdP 那边开了断言加密——OpenAI 解不了密，会静默失败。
- 把 Enterprise SSO 和个人 Google 登录搞混——两套配置完全独立。
- 直接在生产改 claim 没留回滚方案——老配置一定要先导出存好。
- 所有管理员都用 SSO——SSO 一挂，没人能进去修。
- 以为 SCIM 是实时的——它一般是 10-40 分钟一次的定时任务。
常见问答
Q：重传证书会把当前登录的人踢下线吗？ A：不会。已经登录的会话在 token 到期前都还能用。只有新发起的登录走新证书 / metadata。
Q：SAML-tracer 显示 response 已签名，OpenAI 还是说 “invalid” 或 “user not found”，怎么回事？ A：response 签名里的证书 thumbprint，和 OpenAI 手里那张对不上——就是教科书式的证书轮换不匹配。从 IdP 重新导出再粘一次；有时候 metadata URL 返回的证书和实际 SSO endpoint 用的还不一样。
Q：OpenAI 说 “user not found”，但用户明明在 IdP 里，怎么办？ A：查两点。第一，上面说的 X.509 证书不匹配（最常见）。第二，IdP 发出去的邮箱得和用户的 OpenAI 账号完全一致——如果 SCIM 推过去的是另一个主邮箱，断言就映射不上。
Q：能用加密的 SAML 断言来加固安全吗？ A：不能。OpenAI 解不了密的 SAML response，所以加密必须关掉。response 签名保持开着即可——OpenAI 验的就是这个。
Q：每次 IdP 改动都得联系 OpenAI 支持吗？
A：不用。证书、metadata、常规 claim 变更都能在 chatgpt.com/admin/identity 自助完成，只有非自助的映射变更才需要开工单。
Q：我只改了 API Platform 那边的 SSO，为什么 ChatGPT 也跟着挂了？ A：每个 IdP 它们共用一个 SSO 连接。任意一边改证书或属性，两边都会生效。