Troubleshooting

Not working? Common SAML errors

The error message depends on the tool, but the causes are almost always the same. Find yours.

Tip: paste the SAML response into the decoder or use the test SP to see exactly which check fails.

"Invalid audience" / "Audience restriction"Audience

Probable cause. The assertion is meant for a different application name than the one the application expects. The difference can be a single character: trailing slash, http vs https, URL vs URN, capitals.

What to do? Compare the Entity ID declared on the IdP side with the application's (visible in its metadata) and make them strictly identical.
"Incorrect ACS URL" / "Recipient" / "Destination"Destination, Recipient

Probable cause. The address the IdP sends the response to is not exactly the application's. Common case: a reverse proxy turns the application from https to http internally, or adds a path.

What to do? Fix the ACS URL declared on the IdP side (copy it from the application's metadata). Also check the application's public URL setting when it sits behind a proxy.
"Invalid signature" / "digest mismatch"Signature

Probable cause. The content changed after signing, or a component reformatted the XML along the way (gateway, web antivirus, copy-paste).

What to do? Get the raw response (SAMLResponse field) without altering it. Check that the base64 encoding is not broken by line breaks or encoded twice.
"Unknown certificate" / "signature does not match any certificate"Signature

Probable cause. The certificate configured in the application is not the one that signs. Very often, the IdP has renewed its certificate and the application kept the old one.

What to do? Re-import the IdP's current metadata, or copy its current signing certificate. To avoid a cutover break, the IdP should publish both the old and the new one during the transition.
"Assertion expired" / "not yet valid" (NotBefore, NotOnOrAfter)NotBefore, NotOnOrAfter

Probable cause. The application server and IdP clocks are not synchronised, or the validity period is very short.

What to do? Synchronise the servers (NTP). Allow a tolerance of 2 to 5 minutes on the application side. Only lengthen the validity on the IdP side as a last resort.
"Unexpected InResponseTo" / "unsolicited response"InResponseTo

Probable cause. The application cannot find the request the response refers to: session lost in the meantime (blocked cookie, another browser, another tab), several servers without session sharing, or a login started from the IdP while the application forbids it.

What to do? Restart the login from the application in a single tab. Behind a load balancer, share the session state. For IdP-initiated, allow it explicitly if that is intended.
"NameID missing" or unexpected formatNameID

Probable cause. The application expects an email address and the IdP sends an opaque identifier (or the reverse).

What to do? Align the format: emailAddress or persistent on both sides, and check that the IdP has the matching value for the user.
The attributes (name, groups…) are emptyAttributes

Probable cause. The IdP does not send the attribute, or sends it under another name (mail, email or a long URI-style name).

What to do? In the IdP, add the attribute to the list sent to this application; in the application, enter the exact name, case included.
Infinite redirect loop

Probable cause. The application cannot create its session after the response (blocked cookie, Secure on internal http, or an ACS that itself redirects to the login).

What to do? Check the session cookies (domain, Secure, SameSite) and that the ACS is not protected by the very login it is meant to complete.
The user is authenticated but "access denied"

Probable cause. On the IdP side, the user is not assigned to the application, or their groups do not match the application's rules.

What to do? Assign the user (or their group) to the application in the IdP, then check the group attributes being sent.
"Encrypted assertion" unreadableEncrypted assertion

Probable cause. The IdP encrypts assertions but the application does not have the decryption key, or the wrong encryption certificate was given to the IdP.

What to do? Give the IdP the application's encryption certificate (use="encryption") and keep the matching private key. ID-Kit does not decrypt yet: disable encryption for the test.
"Unable to decode SAMLRequest"Redirect

Probable cause. With the Redirect binding, the request is compressed (deflate) before base64. A tool that only decodes base64 sees unreadable characters.

What to do? Use the ID-Kit decoder, which handles compression, or check that the URL was not truncated.
"Status: RequestDenied" / "AuthnFailed"Status

Probable cause. The IdP refuses: unknown application (undeclared Entity ID), undeclared ACS, unknown user, or failed authentication.

What to do? Read the StatusMessage and the IdP's log. Check that the application is declared there with the right Entity ID and the right ACS.

Want to see it for real? ID-Kit plays the role you are missing and shows you each step.

Open my spaceDecode a SAML response