A subset of users can’t authenticate via SSO following a certificate rotation in Okta. The login process fails with a “SAML response validation error” in the browser.
The SAML assertion contains the correct NameID and attribute mappings, but JIT provisioning isn’t triggering for new users. A call to GET /api/v2/identityproviders/okta shows the configuration is active.
This behavior is similar to a community thread regarding attribute mismatch, but the assertion XML looks clean.
Thanks . A “SAML response validation error” usually means the trust anchor is broken. When you rotate a certificate in Okta, the Identity Provider (IdP) signs the SAML assertion with a new private key, but the Service Provider (SP) still holds the old public certificate. Since the signature doesn’t match the stored certificate, the SP rejects the token before it ever reaches the JIT logic. It’s a cryptographic mismatch.
You’ll need to update the configuration via PUT /api/v2/identityproviders/okta. Ensure the certificate field in the request body contains the exact base64 encoded public key from the new Okta cert. If the certificate value doesn’t align with the signing key used by Okta, the system won’t validate the assertion, which explains why JIT never triggers. It’s not a mapping issue; it’s a handshake failure.
did you check if the metadata url is actually updating in the config? the earlier reply is spot on about the trust anchor.
we saw something similar when syncing the Bold360 knowledge base for chatbot handoff and it’s usually a caching thing. try a PUT /api/v2/identityproviders/okta to the refresh.