Back

SAML Parser

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between identity providers (IdPs) and service providers (SPs). This tool decodes SAML messages from URLs, handles Base64 and DEFLATE encoding, and pretty-prints the XML for inspection.

Specifications

Common Use Cases

  • Debug enterprise Single Sign-On (SSO) authentication flows
  • Inspect SAML assertions from identity providers (Okta, Azure AD, ADFS)
  • Troubleshoot SAML integration between services
  • Verify assertion attributes and NameID values
  • Analyze AuthnContext and session parameters
  • Audit SAML configurations for security review

Features

  • Parse SAML AuthnRequest messages (SP to IdP)
  • Decode SAML Response and Assertions (IdP to SP)
  • Extract SAMLRequest and SAMLResponse from URL query parameters
  • Handle Base64 encoding and DEFLATE compression (HTTP-Redirect binding)
  • Pretty-print XML structure with syntax highlighting
  • Display message overview (type, ID, IssueInstant, Destination, Status)
  • Extract Issuer, Subject/NameID, and Conditions
  • Display assertion attributes from AttributeStatement
  • Signature presence indicator

Examples

SAML Response URL

Try it →

A URL containing a Base64-encoded SAML Response in the query string.

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Tips

  • SAML uses two main bindings: HTTP-Redirect (GET with deflate+base64) and HTTP-POST (POST with base64).
  • The RelayState parameter preserves the original requested URL through the SSO flow.
  • SAML assertions can be signed, encrypted, or both. This tool shows decoded content.
  • Check the NotBefore and NotOnOrAfter conditions to validate assertion timing.

Understanding SAML

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). SAML 2.0, published by OASIS in 2005, remains the dominant protocol for enterprise Single Sign-On (SSO), enabling employees to authenticate once and access multiple applications.

A SAML SSO flow works as follows: a user attempts to access a service provider, the SP generates an AuthnRequest and redirects the browser to the IdP, the IdP authenticates the user and creates a SAML Response containing Assertions, and the browser POSTs this Response back to the SP. The assertion contains the user's identity (NameID), attributes (email, groups, roles), and conditions (validity window, audience restriction).

SAML messages are transported using bindings. The HTTP-Redirect binding encodes XML using DEFLATE compression and Base64 encoding in a URL query parameter. The HTTP-POST binding uses only Base64 and submits via an auto-submitting form. Debugging SAML requires decoding these layers to inspect the underlying XML.

SAML assertions can be signed (to prove they came from the IdP), encrypted (to prevent intermediaries from reading contents), or both. When troubleshooting SSO issues, the first step is always to decode the SAML Response and check the assertion's conditions, audience, timestamps, and attribute values.

SAML and OAuth 2.0/OpenID Connect serve different purposes. SAML is designed for enterprise SSO using XML-based assertions transported via browser redirects, and is most common in enterprise environments with identity providers like ADFS and Okta. OAuth 2.0 is an authorization framework for API access using JSON tokens, and OpenID Connect adds an authentication layer on top of OAuth using JWTs. OIDC is more common in modern web and mobile applications, while SAML remains dominant in corporate IT environments.

SAML messages often appear as unintelligible strings because they are encoded for transport. In the HTTP-POST binding, the XML is Base64-encoded. In the HTTP-Redirect binding, the XML is first DEFLATE-compressed, then Base64-encoded, then URL-encoded. Reading the original XML requires reversing these layers in the correct order. This tool handles all decoding steps automatically regardless of which binding was used.

When troubleshooting SAML errors, check several common causes: clock skew between the IdP and SP can cause assertion timestamps to fail validation; the Audience element must exactly match the SP's configured entity ID; assertions may have expired past their NotOnOrAfter time; the Destination attribute must match the SP's Assertion Consumer Service (ACS) URL; and the SP may not have the IdP's current signing certificate if it was recently rotated. The RelayState parameter also plays an important role in the SSO flow — it preserves the user's originally requested URL through the authentication redirect, so that after successful authentication, the SP can redirect back to the page the user initially tried to access.

← Back to all tools