How to use
What this is
Paste a SAMLResponse/SAMLRequest — the full URL of a Redirect binding, the base64 value of a POST binding, or the already-decoded XML — and it decodes and audits it: signature, algorithms, expiry, audience, and the classic XML Signature Wrapping (XSW) attack pattern. Nothing leaves your browser.
Verifying the signature
If you paste the IdP's signing certificate (as PEM, as base64 the way it appears in the metadata, or the whole metadata), it really checks each signature: that what was signed hasn't changed (the digest) and that it was signed by that certificate's key. Never with the certificate inside the message, in KeyInfo: the signer puts that one there, and an attacker puts their own. A valid signature isn't enough: it must also cover the assertion your application reads, and that is what the XSW rule checks. It verifies with xmldsigjs, checked against responses signed by real IdPs.
What this does NOT do
It doesn't decrypt encrypted assertions (that would need the service provider's private key, which shouldn't be pasted anywhere), doesn't check the IdP certificate's chain (in SAML it is trusted because it is in the metadata, not because of who issued it), and doesn't know which ID your application really reads: if your code picks the assertion another way, XSW can still slip through.
What is XSW?
XML Signature Wrapping: an attacker injects a new element (with the same ID as the original, or a different one) so that the code that validates the signature looks at one thing and the code that reads the data looks at another. It still breaks SSO implementations in production — PortSwigger documented it again in 2025.
