Identity Protocol Lab

SAML Response Decoder and Identity Artifact Inspector

Paste a SAML response — raw XML, base64, URL-encoded, or the whole SAMLResponse=… form-post body copied out of your browser’s network tab — and this tool decodes it in your browser and pulls out the fields that actually decide whether a login works: issuer, NameID, audience restriction, destination, recipient, the NotBefore and NotOnOrAfter window, the declared signature algorithm, and whether a signature element is present at all.

The same inspector also reads JWKS key sets, OIDC discovery documents, WebAuthn registration JSON, and SCIM resources, because a federation problem rarely stays inside one format. Nothing is uploaded. Assertions routinely contain names, email addresses, and group memberships, and a browser-local decoder is the only kind you should be pasting those into.

Debugging a Failed SAML Login

Most SSO failures come down to one of a handful of mismatches, and each has a specific field to look at. Decode the response, then work down this list:

Be clear about the signature line in that table. This tool reports whether a <Signature> element exists, whether an <EncryptedAssertion> is present, and which algorithm the SignatureMethod declares. It does not cryptographically verify the signature, because doing so requires the IdP certificate you expect plus canonicalisation of the exact document. A structurally present signature tells you the IdP signed something; it never tells you the signature is valid or that the key is one you trust.

That distinction is worth internalising, because “the signature element is there” is exactly the observation that makes people stop looking and conclude the SP is broken. The most common real cause of an invalid-signature error is that the SP is still holding the IdP’s previous signing certificate.

What the SAML Decoder Extracts

• Issuer — the entity ID the assertion claims to come from, which is what the SP compares against its configured trust.
• NameID — the subject identifier, and the value most SPs key the user record on.
• Audience — the audience restriction. Its absence is flagged, because an assertion with no audience restriction can be replayed at a different service provider.
• Destination and Recipient — where the IdP believes this response should be delivered.
• NotBefore and NotOnOrAfter — the validity window, compared against your clock right now.
• SignatureMethod algorithm — flagged at high severity when it names SHA-1.
• Signed and encrypted flags, plus attribute count — a quick read on whether attributes are being released at all.

Input handling is deliberately forgiving in one direction and strict in the other. A SAMLResponse= parameter is unwrapped, URL-encoding is undone, and base64 is decoded, all automatically. But any input containing a <!DOCTYPE> or <!ENTITY> declaration is rejected outright rather than parsed — entity expansion in XML is how XXE and billion-laughs attacks work, and there is no legitimate reason for a SAML response to carry a DTD. Artifacts are capped at 512 KiB.

JWKS Key Set Inspection

Point the inspector at a jwks.json and it reports the key count, the key types present, and every kid, then checks the two things that go wrong in practice:

• Private key material in a public key set — flagged critical. RSA and EC private parameters (d, p, q, dp, dq, qi, oth) have no business in a published JWKS, and exporting a whole key pair instead of just the public half is an easy mistake to make. If this fires on a set you have already published, rotate the key.
• Duplicate key identifiers — flagged medium. Two keys sharing a kid makes key selection ambiguous, and which one a verifier picks is implementation-defined. This is a classic cause of signature failures that affect only some tokens, appearing right after a rotation.

A set declaring alg of none, or containing no usable key objects at all, is flagged too.

OIDC Discovery, WebAuthn, and SCIM

An OIDC discovery document is checked for the things a client integration depends on: the issuer and the authorization, token, and JWKS endpoints must all be present and must all be HTTPS; code_challenge_methods_supported should advertise S256, which public clients need; and id_token_signing_alg_values_supported is flagged if it offers none. Grant types and response types are listed as facts so you can confirm the flow you are building is actually supported.

WebAuthn registration JSON is checked for a credential type of public-key and a present id or rawId, and its response fields are listed. The tool is explicit about what it cannot do here: challenge, origin, RP ID, signature, signature counters, and attestation trust all require the ceremony context from your own server and are not verified.

SCIM resources are checked for a standard urn:ietf:params:scim:schemas: schema URN and a usable identifier. This is a shape check on a document you paste — it does not contact a SCIM service or authorise any provisioning operation.

Auto-Detection and Explicit Types

Left on auto-detect, the inspector routes by shape: three dot-separated segments with no angle bracket is treated as a compact JWT; anything starting with < or SAMLResponse= is treated as SAML; a JSON object is classified by its own contents — a keys array means JWKS, an issuer alongside an authorization or token endpoint means OIDC discovery, rawId or clientDataJSON means WebAuthn, and a schemas array means SCIM.

Choosing the type explicitly is the better move when something will not decode, because auto-detect returns a generic “type could not be detected” while an explicit choice returns the real parse error — which segment failed, or which element was missing. That error message is usually the answer.

PKCE Pairs and Local Evidence

A PKCE generator sits alongside the inspector for the moments you need a valid pair while testing an authorization request: 48 bytes of cryptographically random data become a base64url verifier, and its SHA-256 digest becomes the S256 challenge. The verifier is deliberately never written into a saved workspace or into the URL — only the challenge is retained, because a verifier that has been persisted somewhere is no longer serving its purpose. For building complete authorization flows, redirect URIs, and provider round-trips, the OAuth and OIDC debugger is the dedicated tool.

Saved workspaces hold the normalised facts and findings, your notes and tags, never the raw artifact. They live in this browser’s local storage, expire after 30 days, and cap at 24 workspaces of 128 KiB. A saved workspace carries across to the linked tools through the URL, so a decode here can continue into a dedicated verification workflow without re-pasting the token.

How to Decode a SAML Response

1. Capture the response. In your browser’s network tab, find the POST to the SP’s ACS URL and copy the SAMLResponse form value. Copying the entire SAMLResponse=… body is fine.
2. Paste it in and leave the type on auto-detect, or choose SAML explicitly if the input is unusual.
3. Select Inspect locally. Decoding happens in the browser; nothing is sent anywhere.
4. Compare audience and destination against the SP’s configured entity ID and ACS URL, character for character.
5. Check the validity window against the time of the failed login, not the time you are debugging.
6. Read the findings panel for missing signatures, SHA-1 algorithms, missing audience restrictions, and expiry.
7. Save the workspace if you are handing the investigation to someone else, then continue into a dedicated verification tool.

Frequently Asked Questions

Can this verify the SAML signature?

No, and no decoder that does not hold your expected IdP certificate can. The tool reports whether a signature element exists and which algorithm it declares. Real verification needs the IdP’s signing certificate, correct XML canonicalisation, and a decision about whether you require the response signed, the assertion signed, or both — which is your SP’s configuration, not a property of the document.

My SAML response will not decode. What is wrong?

Usually the capture, not the response. Confirm you copied the SAMLResponse and not the SAMLRequest, that you took the value from the POST to the ACS URL rather than from the redirect that started the flow, and that you did not copy a truncated value from a log line. If it was pasted out of a URL it may be double URL-encoded — decode once by hand and try again. Selecting SAML explicitly gives you the real parse error instead of a generic detection failure.

Is my token or assertion sent to a server?

No. Every parse, decode, and check runs in your browser, and the raw artifact is excluded from saved workspaces. This matters more here than for most tools: assertions and tokens carry real identity data and are frequently still valid when you are debugging them.

The assertion has no audience restriction. Does that matter?

Yes. The audience restriction is what binds an assertion to one service provider. Without it, an assertion obtained for one SP can be presented to another, and a correctly implemented SP should reject it. Fix it at the IdP rather than relaxing validation at the SP.

My JWKS shows “private JWK material present”. What should I do?

Treat the key as compromised if that set was ever published. Exporting the full key pair instead of the public half is a common slip, and anything reachable on the internet should be assumed collected. Generate a new key, publish only the public parameters, and rotate.

Why do only some of my tokens fail signature verification?

Look for duplicate kid values in the JWKS, which this tool flags. When two keys share an identifier, which one a verifier selects is implementation-defined, so tokens signed by one key verify and tokens signed by the other do not. It shows up immediately after a rotation and looks maddeningly intermittent.

Does this contact my identity provider or SCIM endpoint?

No. Everything is a local inspection of a document you paste. No discovery URL is fetched, no JWKS is retrieved, and no provisioning operation is attempted or authorised.

Do I need an account?

No. This and the rest of our security tools are free and need no signup. For decoding and validating JSON Web Tokens specifically, use the JWT decoder and validator; for designing federation and trust relationships, see the federated identity architect.