SAML-Antwort-Decoder

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