ChatGPT Enterprise SSO fails right after the identity provider (Okta, Azure AD, Google Workspace, JumpCloud, etc.) gets a config change — the redirect chain looks fine until the SAML POST hits OpenAI and gets bounced with “SAML response invalid” or “user not found”. The shortest fix path is: re-export IdP metadata, re-upload to platform.openai.com Enterprise admin, then confirm NameID and email claim alignment. Almost never an OpenAI-side outage — start from the IdP audit log.
Common causes
1. SAML signing certificate rotated; OpenAI still holds the old one
IdPs rotate signing certs every 1-2 years. If the rotation happened on the IdP side but the new metadata XML never got re-uploaded to OpenAI, every SAML response now fails signature verification.
How to judge: Okta / Azure admin → Application → SAML signing certificate → check thumbprint and “valid from” date. If newer than last upload to OpenAI, that is your cause.
2. NameID format changed (email → persistent ID or vice versa)
OpenAI Enterprise expects NameID to be the user’s email (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress). If the IdP admin switched to persistent or unspecified to support a different SaaS, OpenAI cannot map the user.
How to judge: Capture the SAML response (SAML-tracer browser extension), look at <NameID Format="...">. Anything other than emailAddress will fail.
3. Email attribute claim renamed or removed
Some IdPs use email, some use EmailAddress, some use http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. OpenAI maps a specific attribute name during initial setup; if the IdP admin renamed it, mapping breaks.
How to judge: SAML response <AttributeStatement> — does it contain the exact attribute name OpenAI was configured to read?
4. SCIM provisioning fell behind; user not yet pushed
ChatGPT Enterprise with SCIM enabled only lets pre-provisioned users in. If a new hire was added in the IdP but SCIM has not synced yet (or is paused), login fails with “user not authorized”.
How to judge: platform.openai.com → Enterprise admin → Users — is the user listed? If not, SCIM has not pushed them yet.
5. IdP group claim no longer matches OpenAI’s allowed groups
Some Enterprise tenants restrict access by group claim (e.g., only chatgpt-users group). If the IdP admin renamed the group or removed the user from it, the SAML response succeeds but OpenAI rejects authorization.
How to judge: SAML response should contain a groups or MemberOf claim with the expected value.
Before you start
- Confirm this is an Enterprise SSO issue, not personal Google/Apple SSO — they are completely different flows.
- Have IdP admin access ready (Okta admin, Azure portal, Google admin console) — most fixes require it.
- Install SAML-tracer or Chrome’s “SAML Chrome Panel” to capture the actual SAML response.
Information to collect
- Exact error text on the OpenAI side (“SAML response invalid”, “user not found”, “no matching account”).
- IdP type and version (Okta, Azure AD, Google Workspace, JumpCloud, OneLogin).
- Date and nature of the last IdP-side change (cert rotation, metadata edit, attribute mapping change, SCIM pause).
- A captured SAML response XML (sanitized — strip the signature value).
- OpenAI Enterprise workspace ID and the admin email.
- IdP audit log entries for the failed login attempts.
- Whether any users can still log in successfully (narrows it to a per-user vs tenant-wide problem).
Step-by-step fix
Step 1: Confirm the blast radius
In the IdP admin console, check the audit / system log for the OpenAI app. If every login attempt fails, the problem is at the metadata / cert / claim layer. If only some users fail, focus on SCIM provisioning or group membership.
Step 2: Re-upload IdP metadata to OpenAI
Most fixes start here. From the 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 metadataThen at platform.openai.com → Enterprise admin → SSO → upload the new XML (or paste the URL). OpenAI will re-validate signature with the new cert.
Step 3: Verify claim mapping
OpenAI Enterprise SSO expects, at minimum:
| OpenAI field | Expected SAML attribute |
|---|---|
| NameID | User email, format emailAddress |
| User primary email | |
| firstName | Given name |
| lastName | Family name |
If your IdP admin recently renamed any of these attributes, restore the original names or update the OpenAI-side mapping accordingly (requires an OpenAI support ticket for non-self-serve fields).
Step 4: Test with SAML-tracer
Open SAML-tracer in a fresh browser window, sign in. Inspect the captured response:
1. <Signature> block present and validates against the uploaded cert
2. <NameID Format="...emailAddress"> contains the user's email
3. <AttributeStatement> has email/firstName/lastName claims
4. <Conditions NotBefore/NotOnOrAfter> covers the current time (clock skew check)Any failure here pinpoints the root cause without guessing.
Step 5: For SCIM issues, force a re-sync
If a specific user cannot log in but others can:
- Okta: Provisioning → Force sync, or remove and re-assign the user
- Azure AD: Provisioning → Restart provisioning, then check the user under “On-demand provisioning”
- Google: User auto-provisioning is delayed — wait 10 min or manually create the user in platform.openai.com
Verify the user appears in platform.openai.com → Enterprise admin → Users before retrying login.
Step 6: Coordinate with OpenAI Enterprise support
If steps 1-5 do not resolve, file a priority ticket via your dedicated Enterprise Slack channel or enterprise-support@openai.com. Include the sanitized SAML response, IdP audit log entries, and the exact timestamp of a failed login. Enterprise SLA is typically 4 business hours.
Verify
- A test user from each access tier (member, admin, SCIM-provisioned, group-restricted) can log in successfully.
- SAML-tracer shows a clean signed response with all expected attributes.
- platform.openai.com → Enterprise admin → Audit log shows the test logins as successful.
- IdP audit log shows no warning entries for the OpenAI application.
- Repeat the test in an incognito window 30 minutes later to rule out cached state.
Long-term prevention
- Subscribe IdP admin to cert expiration alerts at least 30 days before rotation; pre-stage the new metadata.
- Document the exact SAML attribute names mapped to OpenAI in your runbook — do not rely on memory.
- Test a staging Enterprise workspace whenever the IdP admin plans a major config change.
- Keep at least one “break-glass” local admin account (non-SSO) at platform.openai.com so admins can fix SSO if it fails.
- Schedule quarterly SSO health checks — capture a SAML response and verify all expected claims are present.
Common pitfalls
- Re-uploading metadata but forgetting to restart the IdP-side session — old SAML responses still get sent until the IdP cache flushes.
- Confusing Enterprise SSO with personal Google SSO — they use entirely separate config paths.
- Editing claims in production without a rollback plan — keep the old config exportable.
- Letting all admin accounts be SSO-only — when SSO breaks, no one can fix it without OpenAI support involvement.
- Assuming SCIM auto-sync is instant — it is typically scheduled every 10-40 minutes depending on the IdP.
FAQ
Q: Does re-uploading metadata kick out current sessions? A: No. Existing sessions remain valid until their token expires (typically 8-24 hours). Only new login attempts use the new metadata.
Q: Can I roll back if the new metadata breaks things? A: Only if you saved the previous XML. Always export and store the old metadata before uploading the new one.
Q: Why does SAML-tracer show a signed response but OpenAI still says “invalid”? A: The cert thumbprint in the response signature does not match the cert you uploaded. Re-export from the IdP — sometimes the metadata URL serves a different cert than the SSO endpoint.
Q: Do I need to involve OpenAI support for every IdP change? A: No — most metadata, cert, and claim updates are self-serve from the Enterprise admin. Only schema-level mapping changes need a ticket.
Q: What if SCIM is showing the user as “provisioned” but they still cannot log in? A: Check that the user’s IdP-side primary email matches the SCIM email pushed to OpenAI. A mismatch causes “user not found” even with successful provisioning.
Related
- ChatGPT account switch not working
- ChatGPT Team seat not active
- ChatGPT organization switch not sticking
- ChatGPT 2FA locked out
- Wrong auth method after signup
Tags: #ChatGPT #Troubleshooting #sso