OAuth2 & OpenID Connect Debugger — SAML Response Decoder

← Return to SAML Test Tools

Take a SAML response off the wire and read it, in SAML 2.0 or SAML 1.1. Paste an HTTP-POST form body, a full redirect URL or query string, a bare SAMLResponse parameter, an artifact, a bare <saml:Assertion>, or the XML itself — the binding is worked out from the blob. Everything runs in your browser: nothing is sent anywhere, and no key you paste is written to storage. Signature validation and decryption are both optional and each is switched on separately, because a response that is neither signed nor encrypted still decodes.

A response is signed in two places, and they are different claims. An identity provider may sign the <samlp:Response>, or each <saml:Assertion> inside it, or both. Only the assertion signature survives the assertion being lifted out and forwarded; only the message signature covers the <samlp:Status> and the InResponseTo. This page checks every signature it finds and reports each one separately — a decoder that answered "signed: yes" would be telling you your unsigned assertion is safe.

Collapse all panes Tip: click a pane's title to collapse/expand it.

Message

Binding

Response

Binding parameters

What the blob carried beside the message itself. saml-profiles-2.0-os §4.1.2 says the Redirect binding MUST NOT carry a response — it usually will not fit in a URL — so a response that arrived that way is worth noticing rather than assuming.

Digital Signatures (optional)

Validate the digital signatures

Every signature found is checked and reported on its own line: the one on the message, the one on each assertion, and — if the response arrived on the Redirect binding — the detached one over the query string (saml-bindings-2.0-os §3.4.4.1), which has nowhere to put a KeyInfo and therefore needs the certificate below. An enveloped signature normally carries its own certificate and needs nothing pasted.

Signer Certificate View certificate details →

Decryption (optional)

Decrypt the encrypted structure

The recipient's key pair. Only the private key decrypts; the certificate is optional and is used to say whether this is the key the sender actually wrapped to — a mismatch there is the ordinary reason a decryption fails, and it is invisible otherwise. Prefilled from the SP key on the SAML Test Tools page when that page is keeping one. Nothing pasted here is stored.

Private Key (PKCS#8 PEM)

Certificate (optional)

Decrypting an <saml:EncryptedAssertion> puts the plaintext assertion back into the response in place of the ciphertext, so the Assertions tab and the signature check below then operate on the assertion itself. A signature that was outside the ciphertext never covered that plaintext, which is why the two are reported separately.

Decoded Message

The blob exactly as it was pasted, and the encoded message parameter pulled out of it.

Original blob

Encoded message parameter

The <xenc:EncryptedData> found in the decoded response, with the wrapped session key beside it when the sender put it there. This is exactly what the Decryption pane operates on.

Encrypted structure

The base64-decoded (and, on the Redirect binding, inflated) message, pretty-printed. The indentation is display only — a signature is computed over the bytes as sent, so verification uses the original serialization rather than what is shown here.

Decoded XML

The values worth reading, in whichever protocol version the message is written in. The status is the point of a response: SAML 2.0 writes its code as a URI and SAML 1.1 writes it as a QName resolved against the document's own namespace declarations, so the same verdict is spelled urn:…:status:Success in one and samlp:Success in the other.

Every assertion the response carries — its own signature, its conditions, how it says it was confirmed, and its attributes. An assertion inside an <saml:Advice> is labelled as such: that is supporting material rather than the subject of the response, and a relying party may ignore it entirely.

Tools

Standalone utilities for working with SAML and its XML security layers.

SAML Request Decoder — the mirror of this page: take an AuthnRequest off the wire and read it, on any of the three bindings.

SAML Assertion Tool — compose a spec-compliant SAML 1.0/1.1/2.0 assertion (optional elements, NameID, custom attributes), sign it with XML Signature, and encrypt it with XML Encryption.

Certificate Details — parse an X.509 certificate (PEM or bare base64 DER) and inspect its subject, issuer, validity, key, extensions, and fingerprints.

Certificate Authority & X.509 Tools — build a Root, Intermediate and Issuing certificate authority, issue TLS server/client, code-signing, S/MIME and other certificates with every X.509v3 extension, and test a real TLS or mutual-TLS handshake with what you issued.