Why it matters
When single sign-on fails, the SP's log usually says little more than "invalid response". The cause is nearly always one of a handful: an audience that doesn't match the SP's entity ID, a response that arrived after NotOnOrAfter because the clocks drift, an ACS URL that differs from the one registered at the IdP, an error status from the IdP, or a signature on the wrong element.
This decoder unpacks the message the same way an SP does, from base64 or deflated base64, and runs those checks against your settings and a time you choose. It also maps every XML signature to the element it covers, which is how signature wrapping attacks are spotted: an extra, unsigned assertion placed where a careless SP reads it.
How to use it
- Paste the SAMLResponse from the browser's network tab, or a redirect URL with SAMLRequest.
- Enter your SP entity ID and ACS URL.
- Optionally set the time to check at and the clock skew you allow.
- Read the checks, then the fields, attributes and signatures.
FAQ
How do I capture a SAML response?
Open the browser's developer tools on the Network tab, sign in, and find the POST to your ACS URL. Copy the SAMLResponse form field.
Why is my SAML response expired?
Assertions are valid for a few minutes. If the IdP's and SP's clocks differ, or an old response is replayed, the NotOnOrAfter time has passed. Sync clocks with NTP and allow a small skew.
What is an audience mismatch?
The assertion names the SP it is meant for. If that isn't exactly your SP's entity ID, the SP must reject it. Fix the entity ID in the IdP's settings.
Does this verify the signature?
It checks what each signature covers and which algorithms it uses, which catches wrapping attacks and misconfiguration. Cryptographic verification needs your SAML library and the IdP's metadata certificate.
