# SAML Decoder > Paste a SAML Response or assertion (raw, base64, or URL-encoded) and decode its issuer, status, subject, conditions, audience, and attributes, with signature and weak-algorithm checks. Hardened against XXE. - Tool: https://ronutz.com/en/tools/saml-decoder - Family: Identity & tokens --- ## What it does Paste a SAML Response or assertion, as raw XML, base64, or URL-encoded, and the tool decodes it: the issuer, the status, the subject, the conditions, the audience, and the attributes. It runs a rule-based security assessment alongside the decode, and it parses the XML in a way that is hardened against XXE. Everything happens in your browser. ## SAML in brief SAML, Security Assertion Markup Language, is the XML-based standard behind much of enterprise single sign-on. After you authenticate, an identity provider issues a signed **Assertion**, usually wrapped in a **Response**, that asserts who you are to a service provider. The pieces the tool pulls out are the ones that decide whether that assertion should be trusted: the **Issuer** (which IdP), the **Status** (whether authentication succeeded), the **Subject** and its NameID (who), the **Conditions** (the validity window and the **AudienceRestriction** naming who the assertion is for), and the **Attributes** (the claims about the user). Because SAML travels base64-encoded over the HTTP-POST binding and DEFLATE-compressed over HTTP-Redirect, the tool normalizes those encodings first. ## The security model: XXE rejection The headline property of this tool is how it parses. Untrusted XML is dangerous because of XML External Entity (XXE) attacks and entity-expansion attacks like billion laughs, and both of those require the document to declare a DTD, through a `DOCTYPE` or an `` declaration, to define their entities. A legitimate SAML message never needs a DTD, so the parser rejects any document that contains one outright. That single rule defeats classic XXE and the billion-laughs expansion by construction, rather than trying to sanitize them after the fact. ## What the assessment checks Beyond decoding, the tool evaluates the message against SAML security guidance: whether it is signed, whether it relies on weak signature or digest algorithms (such as SHA-1), and whether its conditions and audience are present and coherent. If the assertion is encrypted, the tool detects the `EncryptedAssertion` and reports it rather than attempting to decrypt it. These checks mirror the questions in the OWASP SAML guidance, so the output points at the things that actually cause SAML vulnerabilities. ## Using it Paste a SAML Response or assertion in any of its common forms and read the decoded issuer, status, subject, conditions, audience, and attributes, along with the security assessment. The parse is deterministic and local, and the XXE-rejecting parser makes it safe to inspect untrusted messages. ## Standards and references - [OASIS - SAML 2.0 Core (assertions and protocols)](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) - Assertion / Response structure, Subject, Conditions, Status, NameID - [OASIS - SAML 2.0 Bindings](https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) - HTTP-POST (base64) and HTTP-Redirect (DEFLATE) message encodings - [OASIS - SAML 2.0 Profiles (Web Browser SSO)](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) - Web Browser SSO profile: bearer confirmation, audience, recipient checks - [W3C - XML Signature Syntax and Processing 1.1](https://www.w3.org/TR/xmldsig-core1/) - ds:Signature, SignatureMethod / DigestMethod / CanonicalizationMethod URIs - [W3C - XML Encryption Syntax and Processing 1.1](https://www.w3.org/TR/xmlenc-core1/) - EncryptedAssertion / EncryptedData structure (detected, not decrypted) - [OWASP - XML External Entity (XXE) Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) - why a DTD / external entity must be rejected when parsing untrusted XML - [OWASP - SAML Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) - signature, audience, recipient, and replay checks for SAML responses ## Related reading - [F5 BIG-IP APM as a SAML Proxy: SP and IdP Modes](https://ronutz.com/en/learn/f5-apm-saml-federation.md): BIG-IP APM (now BIG-IP Zero Trust Access) is a concrete SAML proxy: as a reverse proxy in front of an application it acts as a SAML service provider, delegating login to an external identity provider and then doing single sign-on to the backend; it can also act as a SAML identity provider that federates SSO to SaaS. This maps the generic SAML-proxy roles onto APM's SP service, IdP service, and connector objects. - [Inside a SAML Assertion: Subject, Conditions, and Audience](https://ronutz.com/en/learn/saml-assertions-and-conditions.md): The anatomy of a SAML assertion: the Subject and NameID formats, bearer SubjectConfirmation and the NotOnOrAfter / Recipient / InResponseTo checks, the Conditions validity window, the AudienceRestriction, and the AuthnStatement, with the validation a service provider must perform on each. - [SAML 2.0: How Browser SSO Works](https://ronutz.com/en/learn/saml-overview.md): What a SAML assertion is, the roles of the identity provider and service provider, the SP-initiated Web Browser SSO flow end to end, and the difference between the HTTP-POST and HTTP-Redirect bindings that carry the messages. - [SAML Bindings and SP vs IdP Initiation](https://ronutz.com/en/learn/saml-bindings-and-sso-initiation.md): A SAML flow can start at the service or at the identity provider, and the messages can travel by two different bindings: an HTTP redirect with the message packed into the URL, or an auto-submitting HTML form that POSTs it. Which binding carries which message, and where the flow begins, explains a lot of SSO behavior. - [SAML Signatures and XML-DSig](https://ronutz.com/en/learn/saml-signatures.md): How a SAML message is signed with XML Signature: the enveloped ds:Signature, the SignatureMethod and DigestMethod algorithms, why SHA-1 is weak, the difference between signing the Response and signing the Assertion, and how XML signature wrapping attacks work. - [The SAML Proxy: Inserting an Identity Layer into a Session](https://ronutz.com/en/learn/saml-proxy-explained.md): A SAML proxy sits in the SSO flow rather than the packet path: it terminates the user's request, forces authentication against an identity provider, and only then lets the session through, using SAML's browser-redirect model. It can act as a service provider to the IdP and an identity provider to the app at once (a proxy or broker), which is how one login federates many downstream systems. This explains the roles, the flow, and why it is a proxy at all. - [XXE and Why a SAML Parser Rejects DOCTYPE](https://ronutz.com/en/learn/xxe-and-xml-security.md): How XML External Entity (XXE) attacks work, the billion-laughs denial-of-service, why both depend on a DTD, and why a hardened SAML decoder rejects any DOCTYPE or entity declaration outright rather than trying to parse it safely.