ChatGPT Enterprise (or Business) SSO fails right after the identity provider (Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, etc.) gets a config change. The redirect chain looks fine until the SAML POST hits OpenAI and gets bounced with SAML response invalid, user not found, or no matching account.
Fastest fix (works ~80% of the time): re-export the IdP’s current signing certificate, then re-paste the X.509 cert (or re-upload metadata) on the OpenAI Identity & Provisioning page at https://chatgpt.com/admin/identity → SSO. Per OpenAI’s own support docs, user not found “almost always indicates a mismatch in the X.509 certificate you shared with OpenAI vs. what’s being seen in the returned SAML response.” This is almost never an OpenAI outage. Start from the IdP audit log, not status.openai.com.
Admin console moved. As of June 2026 the SSO/SCIM controls live at
chatgpt.com/admin/identity(the Identity & Provisioning tab), with tenant-wide settings in the Global Admin Console atadmin.openai.com. The oldplatform.openai.comSSO panel is the API Platform’s view of the same connection. ChatGPT Enterprise and the API Platform share one SSO connection per IdP, so a change on one side affects both.
Which bucket are you in
Use the error and blast radius to jump straight to the right cause.
| What you see | Most likely cause | Jump to |
|---|---|---|
user not found / no matching account, all users | X.509 cert mismatch (rotated cert) | Cause 1 |
SAML response invalid, all users | Stale cert, or assertion is encrypted | Cause 1 / 6 |
| Login works but lands on wrong/empty account | NameID changed (not emailAddress) | Cause 2 |
user not found, but only new users | Email attribute renamed, or SCIM behind | Cause 3 / 4 |
user not authorized for some users | SCIM not synced, or group claim mismatch | Cause 4 / 5 |
Common causes
1. SAML signing certificate rotated; OpenAI still holds the old one
IdPs rotate signing certs every 1-2 years (Entra ID auto-rotates by default). If the rotation happened on the IdP side but the new cert/metadata never got re-pasted into OpenAI, every SAML response now fails signature verification. OpenAI surfaces this as user not found or SAML response invalid — the cert thumbprint in the signed response no longer matches the cert OpenAI trusts. This is the single most common cause.
How to judge: Okta / Entra admin → Application → SAML signing certificate → check the thumbprint and “valid from” date. If it is newer than your 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, format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. If the IdP admin switched NameID to persistent or unspecified to satisfy a different SaaS app, OpenAI cannot map the user — login may “succeed” but land on a wrong or empty account.
How to judge: Capture the SAML response (SAML-tracer extension) and read <NameID Format="...">. Anything other than emailAddress will misbehave.
3. Email attribute claim renamed or removed
OpenAI keys the account off the email attribute in the assertion. Some IdPs send email, some EmailAddress, some http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. OpenAI recommends sending a single, stable email (a UPN works well) so accounts stay attached. If the IdP admin renamed that attribute, mapping breaks for affected users.
How to judge: SAML response <AttributeStatement> — does it contain exactly the attribute name your IdP’s setup wizard told you to send, and only one email value?
4. SCIM provisioning fell behind; user not yet pushed
With SCIM directory sync enabled, ChatGPT Enterprise only admits pre-provisioned users. 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: chatgpt.com/admin → Members — is the user listed? If not, SCIM has not pushed them yet. SCIM jobs typically run on a 10-40 minute schedule depending on the IdP.
5. IdP group claim no longer matches OpenAI’s allowed groups
Some tenants gate access by a group claim (e.g. only chatgpt-users). If the IdP admin renamed the group or removed the user from it, the SAML response signs fine but authorization is rejected.
How to judge: the SAML response should contain a groups or MemberOf claim with the expected value.
6. The assertion is now encrypted
OpenAI does not support encrypted SAML responses or assertions — it cannot decrypt them, so it can’t read the attributes. If your IdP admin enabled assertion encryption (sometimes a tenant-wide security default), every login fails even with a valid cert.
How to judge: in the IdP SAML app settings, confirm response/assertion encryption is OFF. Signing must stay ON; encryption must stay OFF.
Before you start
- Confirm this is Enterprise/Business SSO, not personal Google/Apple sign-in — completely different flows.
- Have IdP admin access ready (Okta admin, Entra portal, Google admin console). Most fixes require it.
- Install SAML-tracer (Firefox) or “SAML Chrome Panel” to capture the actual SAML response.
- Keep a non-SSO break-glass admin handy (see Long-term prevention) so you can still reach
chatgpt.com/adminwhen SSO is down.
Information to collect
- Exact error text on the OpenAI side (
SAML response invalid,user not found,no matching account,user not authorized). - IdP type and version (Okta, Entra ID, Google Workspace, JumpCloud, OneLogin, PingFederate).
- Date and nature of the last IdP-side change (cert rotation, metadata edit, attribute rename, encryption toggle, SCIM pause).
- A captured SAML response XML, sanitized (strip the signature value and any PII).
- The OpenAI workspace ID and an admin email.
- IdP audit-log entries for the failed login attempts.
- Whether any users still log in (narrows tenant-wide vs per-user).
Step-by-step fix
Step 1: Confirm the blast radius
In the IdP admin console, open the audit / system log for the OpenAI app. If every attempt fails, the problem is at the cert / metadata / claim / encryption layer (Causes 1, 2, 3, 6). If only some users fail, focus on SCIM provisioning or group membership (Causes 4, 5).
Step 2: Re-export the cert and re-upload at chatgpt.com/admin
This resolves most outages. First grab the current signing cert/metadata from the IdP:
Okta: Applications → ChatGPT → Sign On → SAML Signing Certificates →
Actions → View IdP metadata (or copy the X.509 cert)
Entra ID: Enterprise applications → ChatGPT → Single sign-on →
SAML Certificates → App Federation Metadata Url / Certificate (Base64)
Google: Apps → Web and mobile apps → ChatGPT → Download metadataThen in OpenAI: chatgpt.com/admin/identity → SSO → edit the SAML connection → paste the X.509 certificate contents (or the metadata URL) and save. OpenAI re-validates the signature against the new cert. If you have not done it yet, note that at least one domain must be verified (Identity & Provisioning → + Add Domain → add the TXT record at your DNS) before SSO can be enabled at all.
Step 3: Verify claim mapping
OpenAI Enterprise SSO expects, at minimum:
| OpenAI field | Expected SAML attribute |
|---|---|
| NameID | User email, format emailAddress |
| A single, stable primary email (UPN recommended) | |
| firstName | Given name |
| lastName | Family name |
If the IdP admin recently renamed any of these, restore the original names or update the OpenAI-side mapping to match. Some non-self-serve mappings still require an OpenAI support ticket.
Step 4: Test with SAML-tracer
Open SAML-tracer in a fresh window and sign in. Inspect the captured response:
1. <Signature> present and validates against the uploaded cert
2. response/assertion is NOT encrypted (you can read the XML in clear text)
3. <NameID Format="...emailAddress"> contains the user's email
4. <AttributeStatement> has a single email plus firstName/lastName
5. <Conditions NotBefore="..." NotOnOrAfter="..."> covers the current timeIf line 2 fails (the body is <EncryptedAssertion>), that is Cause 6 — turn encryption off. If line 5 fails, you have clock skew: sync both ends to NTP, since most validators allow only ~1-2 minutes of drift.
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
- Entra ID: Provisioning → Restart provisioning, then run the user through Provision on demand
- Google: auto-provisioning is delayed — wait ~10 min, or create the user manually in
chatgpt.com/admin→ Members
Confirm the user appears under chatgpt.com/admin → Members before retrying login.
Step 6: Coordinate with OpenAI Enterprise support
If Steps 1-5 do not resolve it, file a priority ticket via your dedicated Enterprise Slack channel (or the in-product Help → Contact). Include the sanitized SAML response, the IdP audit-log entries, and the exact timestamp of a failed login. Enterprise support typically responds within a few business hours.
How to confirm it’s fixed
- A test user from each access tier (member, admin, SCIM-provisioned, group-restricted) logs in successfully.
- SAML-tracer shows a clean signed, unencrypted response with NameID = email and all expected attributes.
chatgpt.com/admin→ Audit log shows the test logins as successful.- The IdP audit log shows no warning entries for the OpenAI application.
- Repeat in an incognito window ~30 minutes later to rule out cached state.
Long-term prevention
- Subscribe the IdP admin to cert-expiration alerts at least 30 days before rotation; pre-stage the new cert. (Entra ID auto-rotation is the usual silent culprit.)
- Where the IdP supports it, point OpenAI at the App Federation Metadata URL instead of a pasted cert so cert rotation is picked up automatically.
- Document the exact SAML attribute names you map to OpenAI in your runbook — do not rely on memory.
- Keep at least one break-glass local admin (non-SSO) able to reach
chatgpt.com/adminso admins can fix SSO when it breaks. - Run a quarterly SSO health check: capture a SAML response and confirm every expected claim is present and unencrypted.
Common pitfalls
- Pasting the cert but forgetting the IdP still caches the old session — old SAML responses keep getting sent until the IdP cache flushes.
- Turning on assertion encryption at the IdP — OpenAI silently fails because it cannot decrypt.
- Confusing Enterprise SSO with personal Google sign-in — entirely separate config paths.
- Editing claims in production with no rollback plan — keep the old config exportable.
- Letting every admin be SSO-only — when SSO breaks, nobody can get in to fix it.
- Assuming SCIM is instant — it is typically a scheduled job every 10-40 minutes.
FAQ
Q: Does re-uploading the cert kick out current sessions? A: No. Existing sessions stay valid until their token expires. Only new login attempts use the new cert/metadata.
Q: Why does SAML-tracer show a signed response but OpenAI still says “invalid” or “user not found”? A: The cert thumbprint in the response signature does not match the cert OpenAI holds — the textbook cert-rotation mismatch. Re-export from the IdP and re-paste it; the metadata URL sometimes serves a different cert than the live SSO endpoint.
Q: OpenAI says “user not found” but the user clearly exists in the IdP. Now what? A: Two checks. First, the X.509 cert mismatch above (most common). Second, the email the IdP sends must exactly match the user’s OpenAI account — if SCIM pushed a different primary email, the assertion won’t map.
Q: Can I use encrypted SAML assertions for extra security? A: No. OpenAI cannot decrypt SAML responses, so encryption must be off. Keep response signing on; that is what OpenAI validates.
Q: Do I need OpenAI support for every IdP change?
A: No. Cert, metadata, and standard claim updates are self-serve at chatgpt.com/admin/identity. Only non-self-serve mapping changes need a ticket.
Q: I changed SSO on the API Platform side — why did ChatGPT break too? A: They share one SSO connection per IdP. A cert or attribute change on either side applies to both.
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