Debugging SAML SSO: How to Decode a SAMLResponse and Why It's Not XML
A deep dive into debugging broken SAML SSO logins by understanding HTTP-POST and HTTP-Redirect bindings, handling binary blobs, and resolving AADSTS750056 errors.
Stock photo for illustration only, not from the actual event
- Debugging SAML SSO requires understanding payload encoding across HTTP-POST and HTTP-Redirect bindings.
- HTTP-POST uses a single layer of Base64 encoding to deliver direct XML assertions.
- HTTP-Redirect stacks three layers: URLEncode, Base64, and raw DEFLATE without a zlib header.
- Always decode assertions client-side to prevent credential leakage since a SAML assertion acts as a live session token.
You are in the middle of debugging a broken SSO login flow. The identity provider (IdP) redirects back to your application, handing off a massive data blob labeled SAMLResponse . Naturally, you grab it, apply a Base64 decode, and expect clean, readable XML markup in return. Instead, you occasionally encounter binary garbage starting with byte headers like 0x78 and 0x9c that bears no resemblance to markup.
Both outcomes are completely valid. The core difference lies in the specific SAML binding chosen by the IdP, and once you master these two distinct encoding chains, debugging SAML transforms from guesswork into a science. SAML transmits messages including SAMLResponse and SAMLRequest via two HTTP bindings that format payloads differently:
- HTTP-POST binding: The message travels inside a hidden form field that auto-submits via POST, formatted simply as Base64(XML). Decoding the Base64 yields the assertion XML directly, which is the typical response scenario from an IdP.
- HTTP-Redirect binding: The message rides inside a URL query string, necessitating a compact and URL-safe footprint structured as URLEncode( Base64( DEFLATE( XML ) ) ). Skipping straight to Base64 decoding leaves you staring at raw DEFLATE compressor output, explaining the binary garbage often reported. This binding is typically reserved for SAMLRequest and Single Logout.
Stock photo for illustration only, not from the actual event
Grasping the nuances of HTTP bindings is critical for modern web developers integrating enterprise single sign-on solutions. Common debugging frustrations usually stem from the false assumption that all SAML payloads are immediately parseable as plain text XML. Realizing that compression and encoding layers are intentionally applied to satisfy URL length limits and transport security constraints allows engineers to parse authentication logs much more efficiently.
A critical pitfall to avoid is that the redirect binding relies strictly on raw DEFLATE (RFC 1951) featuring zero zlib headers and no checksum. Standard zlib or gzip inflate libraries will choke on the missing header, leading developers to incorrectly conclude that the data blob is corrupted when it simply requires a raw inflate operation. If you are uncertain which binding you are dealing with, a quick heuristic applies: if a Base64 decode reveals text starting with <?xml or <saml , it is POST. If it returns raw bytes, a raw inflate will almost certainly unlock a Redirect payload.
Once you successfully extract the XML, do not just admire the structure because valuable debugging clues reside within specific fields. If your IdP is Azure AD or Entra, you will eventually cross paths with error AADSTS750056, which states that the SAMLResponse must be a properly formed and encoded Base64 string. Despite the wording, the underlying assertion is usually intact, meaning intermediate middleware inadvertently mangled the transport payload. Both scenarios trace back to the same remedy: preserve exact bytes end-to-end and prevent middleware from altering the payload.
"What's the weirdest SAML failure you've had to decode your way out of? Share it in the comments."
PJ Anderson
A SAML assertion functions as a temporary credential. Throughout its short validity window, anyone holding it can potentially impersonate the target user. Consequently, whenever you decode an assertion for troubleshooting purposes, perform the operation entirely client-side. Never paste a production assertion into an arbitrary server-side online decoder, as doing so hands active credentials directly to a third-party server. For fast local decoding, utilize free browser-based utilities that automatically detect bindings, perform URL decoding, Base64 decoding, raw DEFLATE inflation, XML pretty-printing, and claim extraction entirely client-side without transmitting any data upstream.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment