SAML Inspector

Decode a SAMLResponse or AuthnRequest and see who it logs in, for which service and until when — with checks for unsigned assertions, signature wrapping and comment tricks.

Free · no sign-up · updated

Runs entirely in your browser. Nothing you enter leaves this page.

requests since opened: 0
Verify it yourself

This page is served with a security policy your browser enforces: it cannot open connections or load anything from other sites — not even to us.

  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).

tools v0.9.1 · build 0efa119

How to use
  1. Paste the SAMLResponse (Base64), a SAML URL, or the XML — from your browser’s network tab or a SAML tracer.
  2. Read the user, audience, time window and the findings.
  3. Enter your SP’s entity ID and ACS URL for a clear accept / reject.

The SAML login in four messages

The service provider (SP) sends the browser to the identity provider with an AuthnRequest, usually in the Redirect binding: deflated, Base64-encoded and URL-encoded in the SAMLRequest parameter. After sign-in the IdP posts a SAMLResponse back to the SP’s Assertion Consumer Service (ACS) URL, Base64-encoded in a form field. Paste either message, or the whole URL, and it is decoded the same way.

Before creating a session, the SP must check the signature, the issuer, that the audience is its own entity ID, that the recipient is its ACS URL, the time window, and that InResponseTo matches a request it actually sent. “Check it like your SP” does exactly these checks.

Attacks the findings look for

XML signature wrapping moves the signed element and slips an unsigned assertion where the SP will read it, so the signature is valid but covers the wrong data. Comment truncation hides part of a NameID inside an XML comment so some parsers read a different user (the 2018 Duo disclosure, CVE-2017-11427 and related). Unsigned assertions inside a signed response, duplicate IDs and SHA-1 signatures are flagged as well.

When a working login suddenly fails

Look first at the time window (clock skew between servers), then at the audience and recipient after a URL change, and then at the signing certificate: IdPs roll their certificates, and an SP still holding the old one rejects every response. The signing certificate’s fingerprint and expiry are shown so you can compare them with your SP configuration.

Common questions

How do I get the SAMLResponse to decode?

In your browser’s developer tools, open the Network tab, sign in, and find the POST to your application’s ACS URL: the SAMLResponse form field is the value to paste. A SAML tracer extension shows it too.

Why does my SAML login fail?

The most common causes are an audience that doesn’t match the SP entity ID, a wrong ACS (Recipient) URL, clock skew between servers, and a changed IdP signing certificate. “Check it like your SP” tests each of these.

Does this verify the SAML signature?

It finds the signatures and checks them for the structural attacks behind real breaches (signature wrapping, unsigned assertions, comment truncation). Verifying the cryptography needs the IdP certificate in your SP.

Known limitations
  • Signatures are checked for structural attacks, not verified cryptographically.
  • Encrypted assertions can’t be read (they need the SP’s private key).
  • SAML 2.0 only; messages with a DOCTYPE are refused.
  • Browser extensions can read any page — use a private window for sensitive data. How the lock works

Related reading on CipherMind

Standards & references