SAML Status Codes Reference
A SAML response carries a Status with a top-level StatusCode (Success, Requester, Responder or VersionMismatch) and often a nested second-level code that gives the actual reason. The top-level code says which side the problem is on; the second-level code says what went wrong. The same table drives the SAML decoder's verdict panel, so a code you see there has a row here.
Status codes
| Status code | Level | Meaning | Usually | What to check |
|---|---|---|---|---|
| Success | Top-level | The request succeeded. | None | Nothing to fix in the status. If sign-in still fails, the problem is in the other checks: time windows, audience, destination, or the signature. |
| Requester | Top-level | The request could not be performed because of an error on the requester's side. | Requester's side | Read the second-level code and the StatusMessage, then check the request the requester sent: its Issuer, its ACS URL or index, and its NameIDPolicy. |
| Responder | Top-level | The request could not be performed because of an error on the responder's side. | Responder's side | Read the second-level code and the StatusMessage, then check the responder's logs and its configuration for this application. |
| VersionMismatch | Top-level | The responder could not process the request because of the SAML version it used. | Requester's side | Make sure both sides speak SAML 2.0 and that the request's Version attribute is "2.0". |
| AuthnFailed | Second-level | The responder could not authenticate the principal (the user). | The user | Check the user's sign-in at the IdP: wrong password, a locked or disabled account, or a failed MFA step. The IdP sign-in log names the reason. |
| InvalidAttrNameOrValue | Second-level | An attribute name or value in the request was not understood or not allowed. | Requester's side | Check the attribute names and values in the request (for example in an AttributeQuery) against what the responder supports. |
| InvalidNameIDPolicy | Second-level | The responder cannot or will not support the requested NameID policy. | Requester's side | The AuthnRequest asked for a NameID format the IdP will not release. Make the NameIDPolicy Format in the SP's request match the NameID format configured for this app at the IdP, or request the unspecified format. |
| NoAuthnContext | Second-level | The responder cannot authenticate the user in the way the request's authentication context requires. | Requester's side | The request's RequestedAuthnContext (for example PasswordProtectedTransport with Comparison exact) does not match how the user signed in (for example Windows integrated or MFA). Use Comparison minimum, or remove RequestedAuthnContext. |
| NoAvailableIDP | Second-level | A proxying responder could not find a supported identity provider that is available. | Responder's side | Check the proxy's list of upstream identity providers and whether any of them is reachable and enabled. |
| NoPassive | Second-level | The responder could not sign the user in passively, without interacting with them. | The user | The SP sent IsPassive=true and the user has no session at the IdP, so it could not sign them in without showing a login page. |
| NoSupportedIDP | Second-level | A proxying responder supports none of the identity providers the request listed. | Responder's side | Compare the IDPList in the request's Scoping element with the identity providers the proxy knows. |
| PartialLogout | Second-level | Logout finished for this session, but not every session participant confirmed it. | Either side | Some other application may still hold a session. Check which session participants did not answer the logout. |
| ProxyCountExceeded | Second-level | The responder would have to proxy the request further, but the request's proxy limit does not allow it. | Requester's side | Raise or remove ProxyCount in the request's Scoping element, or have the user sign in at the first responder directly. |
| RequestDenied | Second-level | The responder understood the request and chose not to answer it. | Responder's side | For a sign-in, the most common cause is that the user is not assigned to this application at the IdP. Check the user and group assignments, then the IdP sign-in log. |
| RequestUnsupported | Second-level | The responder does not support this request. | Requester's side | Check that the responder supports this kind of message and binding, for example Single Logout or a passive request. |
| RequestVersionDeprecated | Second-level | The responder no longer accepts the protocol version of the request. | Requester's side | Send the request as SAML 2.0. |
| RequestVersionTooHigh | Second-level | The request's protocol version is newer than the responder supports. | Requester's side | Send the request with Version="2.0". |
| RequestVersionTooLow | Second-level | The request's protocol version is older than the responder supports. | Requester's side | Send the request with Version="2.0". |
| ResourceNotRecognized | Second-level | The responder does not recognize the resource the request names. | Requester's side | Check the resource or entity named in the request against what the responder has configured. |
| TooManyResponses | Second-level | The response would contain more elements than the responder can return. | Responder's side | Narrow the request, for example ask for fewer attributes or a single assertion. |
| UnknownAttrProfile | Second-level | The responder does not support the attribute profile the request uses. | Requester's side | Use an attribute profile the responder supports, or leave the profile out of the request. |
| UnknownPrincipal | Second-level | The responder does not know the principal the request names. | Requester's side | Check the NameID or subject in the request: the user may not exist on the responder, or the NameID format or value differs. |
| UnsupportedBinding | Second-level | The responder cannot send the response over the binding the request asked for. | Requester's side | Check ProtocolBinding in the request and the bindings the responder supports, for example HTTP-POST for the response. |
Every code is a URN: urn:oasis:names:tc:SAML:2.0:status: followed by the name in the first column, for example urn:oasis:names:tc:SAML:2.0:status:Responder. Meanings paraphrase SAML Core section 3.2.2.2.
Why an SP rejects a valid-looking response
| Error you see | Element | What to compare |
|---|---|---|
| Audience invalid | Conditions / AudienceRestriction / Audience | The Audience against the SP entity ID, character for character (a trailing slash or letter case is enough to fail). |
| Recipient mismatch | SubjectConfirmationData Recipient | The Recipient against the ACS URL the SP received the response on. |
| Destination mismatch | Response Destination | The Destination against the ACS URL, including scheme, host, port and path. |
| Assertion expired / NotOnOrAfter | Conditions NotOnOrAfter and SubjectConfirmationData NotOnOrAfter | Both times against the SP clock and its allowed skew. A slow browser hop or a drifting server clock is the usual cause. |
| Assertion not yet valid | Conditions NotBefore | NotBefore against the SP clock. The usual cause is an IdP clock running ahead of the SP clock by more than the allowed skew. |
| InResponseTo mismatch | Response InResponseTo and SubjectConfirmationData InResponseTo | InResponseTo against the ID of the AuthnRequest the SP sent. An IdP-initiated (unsolicited) response has no InResponseTo, which some SPs refuse. |
| Signature validation failed | ds:Signature and its KeyInfo certificate | The signing certificate in the SP configuration against the one in current IdP metadata (rotation is the usual cause), and which element the signature covers (Response or Assertion) against what the SP requires. |
| Invalid NameID format | AuthnRequest NameIDPolicy and the assertion NameID Format | The NameID format the SP requests against the one the IdP is configured to release for this application. |
A response can decode cleanly and carry Success yet still be rejected, because these checks run after decoding.
Frequently asked questions
What is the difference between Requester and Responder?
They are the two top-level failure codes. Requester means the request itself was at fault (a bad NameIDPolicy, an unknown ACS URL, an unsupported binding), so the fix is on the side that sent it. Responder means the side answering could not or would not complete it, so the fix is in its configuration or its logs. Either way, read the second-level code: it carries the actual reason.
Why do I get Responder with RequestDenied?
RequestDenied means the responder understood the request and chose not to answer it. For a sign-in, the most common cause is that the user is not assigned to the application at the IdP. Check the user and group assignments for the application, then the IdP sign-in log, which names the policy that denied it.
Where do I see the status code?
In the Status element of the SAML response: StatusCode Value holds the top-level code, a nested StatusCode holds the second-level code, and StatusMessage may add text. Paste the SAMLResponse into the SAML decoder and the verdict panel shows the whole chain with an explanation of each code.