Diagnose SAML responses by status code
Every SAML 2.0 response carries a <Status> element whose StatusCode URI tells
you the outcome. The top-level code is one of Success, Requester, Responder
or VersionMismatch, and an optional nested second-level code explains the
specific reason — AuthnFailed, NoPassive, RequestDenied and so on. This tool
lists every standard code with its full URI, level and which party it blames, so
you can read a failed SSO response quickly.
How it works
SAML status codes live under the urn:oasis:names:tc:SAML:2.0:status: namespace.
The first StatusCode is the top-level verdict: Success means the exchange
completed, Requester points to a fault in the request sent by the service
provider, Responder blames a problem at the identity provider, and
VersionMismatch flags an unsupported SAML version. When more detail is needed, a
second-level StatusCode is nested inside the first. For example a top-level
Responder paired with a second-level AuthnFailed tells you the IdP ran fine but
could not authenticate the user. Because a top-level Success only confirms the
protocol completed, you still validate the assertion’s signature, time Conditions
and AudienceRestriction before trusting it.
Tips and notes
When debugging a broken login, read the second-level code first — it is where the
actionable detail lives. A Requester failure means fix your SP request (NameID
policy, attributes, metadata); a Responder failure means look at the IdP side. If
you see NoPassive, retry the authentication without IsPassive=true. Compare the
full status URI rather than a short name to avoid confusing similarly named codes,
and log the complete <StatusMessage> the IdP returns alongside the code, since it
often contains a vendor-specific explanation.