SAML Assertion Inspector
Decode and inspect a SAML 2.0 Response — raw XML, base64, or base64+deflated.
Overview
The SAML assertion inspector decodes a SAML 2.0 Response in any of its common transit forms — raw XML, base64-encoded XML, or base64+DEFLATE-compressed XML — and pretty-prints the resulting assertion with key attributes called out. Issuer, audience, subject, NotBefore / NotOnOrAfter conditions, attribute statements, and signature presence are all surfaced.
It is the right tool for SSO engineers integrating with Okta, OneLogin, ADFS, or Ping Identity; QA engineers chasing "why does the user get a SAML error"; and security reviewers checking that an IdP's assertions match the SP's expectations. A SAML inspector saves an enormous amount of XML wrangling when an SSO trace shows a 200-line <samlp:Response>.
How it works
SAML 2.0 (OASIS Security Assertion Markup Language) is an XML-based authentication and authorization standard. Browser-mediated SSO flows send the assertion through two main bindings: HTTP-POST (base64-encoded XML in a form field) and HTTP-Redirect (base64-encoded + DEFLATE-compressed XML in a query string). The tool auto-detects the wrapper: if the input starts with <, it is treated as raw XML; otherwise base64-decoded; if the result is binary it is DEFLATE-inflated (RFC 1951 raw deflate, no zlib header) before XML parsing.
Once parsed, the tool walks the DOM to surface the assertion's namespaces, Issuer, Subject/NameID, Conditions (including audience restrictions), AuthnStatement, and every AttributeStatement/Attribute. Signatures are detected and their canonicalization, digest, and signature methods reported — though the tool does not verify the signature against a certificate.
Examples
Input: base64-encoded SAML Response (HTTP-POST form value)
Output:
Issuer: https://idp.example.com/metadata
Subject: alice@example.com (Format: emailAddress)
NotBefore: 2026-05-18T14:00:00Z
NotOnOrAfter: 2026-05-18T14:05:00Z
AudienceRestriction: https://sp.example.com
Attributes:
- email: alice@example.com
- groups: [admins, users]
Signature: present (RSA-SHA256)
Input: base64+deflate (HTTP-Redirect)
Output: same as above
Input: malformed (truncated base64)
Output: Decode error — base64 padding mismatch at byte 412
FAQ
Does this verify the signature?
No. Signature verification requires the IdP's X.509 certificate from its metadata and runs canonical XML through a cryptographic verifier. This tool surfaces what is in the assertion; pair it with an IdP-aware verifier for production checks.
Why is my SAML response sometimes binary?
Because the HTTP-Redirect binding deflates the XML before base64-encoding to keep URLs short. The HTTP-POST binding skips compression. The tool detects both transparently.
What is the Audience restriction for?
It binds the assertion to a specific Service Provider. If the audience does not match your SP's entity ID, the SP must reject the assertion. Mismatches are one of the most common SAML integration bugs.
How long should NotOnOrAfter be?
Short — typically 5–10 minutes after issuance. SAML assertions are bearer tokens, so a long lifetime is a long replay window. If your assertion lifetime is 24 hours, fix the IdP configuration.