SAML Response Decoder - Inspect Assertions

SAML Response (Base64 or XML)

Paste the SAMLResponse value from your IdP POST (Base64) or the decoded SAML XML

Decoded SAML Response

Decoding SAML 2.0 Responses for SSO Debugging

SAML 2.0 (Security Assertion Markup Language) is the enterprise standard for Single Sign-On (SSO) federation, used by organizations to authenticate users across multiple applications through a centralized identity provider. SAML responses are Base64-encoded XML documents containing assertions about user identity, attributes, session conditions, and digital signatures. When SSO integration fails, debugging requires decoding these opaque payloads to inspect their contents — checking assertion validity windows, attribute mappings, audience restrictions, and signature algorithms.

Paste a Base64-encoded SAMLResponse value (from a browser's form POST) or raw XML to decode and inspect all components: assertions with user attributes, conditions with validity windows and audience restrictions, authentication statements with session details, and signature information. All processing happens entirely in your browser — your authentication tokens never leave your device.

Understanding SAML Response Structure

A SAML response contains multiple nested elements that together establish user identity:

Status: Whether authentication succeeded (urn:oasis:names:tc:SAML:2.0:status:Success) or failed with a specific error code
Assertion: The core identity claim containing subject, conditions, attributes, and authentication context
Subject: The authenticated user identifier (NameID) — typically email, persistent ID, or transient session identifier
Conditions: Validity constraints including NotBefore/NotOnOrAfter timestamps and audience restrictions
Attributes: Additional user data (email, name, groups, roles) provided by the identity provider
AuthnStatement: When and how the user authenticated (password, MFA, certificate)
Signature: XML digital signature covering the assertion or entire response

Common SSO Integration Issues

The decoder helps identify common SAML integration failures:

Clock skew: NotBefore/NotOnOrAfter conditions failing because the SP and IdP clocks are not synchronized
Wrong audience: AudienceRestriction contains a different entity ID than the service provider expects
Missing attributes: Required attributes (email, groups) not included in the assertion
NameID format mismatch: SP expects email format but IdP sends persistent/transient identifier
Signature validation: Response signed with a different certificate than the SP has configured

Security Considerations

SAML responses carry sensitive authentication data that requires careful handling:

Replay protection: Assertions should have short validity windows (typically 5 minutes) and unique IDs that the SP tracks to prevent reuse
Signature coverage: The signature must cover the entire assertion — unsigned assertions can be modified by intermediaries
Encryption: Sensitive attributes may be encrypted with the SP's public key to prevent eavesdropping
InResponseTo: Links the response to a specific authentication request, preventing unsolicited response attacks
XML canonicalization: Signatures are verified against the canonicalized XML — whitespace or namespace differences can invalidate otherwise correct signatures

The decoder displays signature presence and algorithm but cannot verify signatures without the IdP's certificate — it is an inspection tool for debugging, not a security validation tool. Always verify signatures in your actual SP implementation using the IdP's published metadata certificate. When debugging production SSO failures, capture the SAMLResponse from your browser's network tab before the POST to the ACS endpoint to get the exact payload your SP receives.

Code Examples

Decoded SAML Assertion Structure

<!-- Decoded from Base64 SAMLResponse -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="_abc123" IssueInstant="2024-03-15T10:30:00Z">
  <saml:Issuer>https://idp.company.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      alice@company.com
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
        NotOnOrAfter="2024-03-15T10:35:00Z"
        Recipient="https://app.example.com/saml/acs"
        InResponseTo="_request_456"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2024-03-15T10:25:00Z"
    NotOnOrAfter="2024-03-15T10:35:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>alice@company.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>engineering</saml:AttributeValue>
      <saml:AttributeValue>devops</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Standards & Specifications

SAML 2.0 Core Specification — Defines assertion structure, conditions, and protocol bindings for SAML 2.0

Frequently Asked Questions

What does the SAML Response Decoder do?

It decodes Base64-encoded SAML 2.0 responses and extracts key elements: assertions, attributes, conditions (NotBefore/NotOnOrAfter), subject (NameID), authentication statements, and digital signature information. You can also paste raw SAML XML directly.

Is my SAML response sent to a server?

No. All decoding and parsing happens entirely in your browser using JavaScript and the browser-native DOMParser API. Your SAML response — which often contains authentication credentials and personal identity attributes — never leaves your device.

What input format does the tool accept?

The tool accepts both Base64-encoded SAML responses (as received from an Identity Provider via the SAMLResponse POST parameter) and raw SAML XML. It automatically detects the format and decodes accordingly.

What SAML elements are extracted?

The tool extracts: Response metadata (ID, IssueInstant, Destination, Status), Issuer, Assertions with their Subject (NameID, confirmation method), Conditions (validity window, audience restrictions), AuthnStatement (session details, authentication context), Attributes (name, values, format), and Signature details (algorithm, digest method, certificate presence).

How do I get the SAML response to decode?

Use your browser's developer tools: open the Network tab, trigger a SAML login, and look for a POST request to your Service Provider's ACS (Assertion Consumer Service) URL. The SAMLResponse parameter in the form data is the Base64-encoded value you can paste into this tool.

Can this tool validate SAML signatures?

No. This tool decodes and displays signature information (algorithm, digest method, reference URI, certificate presence) but does not perform cryptographic signature validation. Signature verification requires the Identity Provider's public key and should be done server-side in your application.

What is the difference between SAML and JWT?

SAML (Security Assertion Markup Language) uses XML and is typically used in enterprise Single Sign-On (SSO) flows between Identity Providers and Service Providers. JWT (JSON Web Token) uses JSON and is more common in API authentication. SAML responses are larger and more complex, but provide richer identity assertions.

Why does my SAML response have no attributes?

Attribute release depends on the Identity Provider configuration. The IdP must be configured to include specific attributes (email, name, groups, etc.) in the assertion. Check your IdP's attribute mapping or attribute release policies.

What is the maximum input size?

The tool warns when input exceeds 500KB and rejects input larger than 5MB. Most SAML responses are under 50KB. Extremely large responses may indicate excessive attribute release or embedded certificates.