SAML defines 'Bindings' to specify how SAML messages are transported between the IdP and SP. Since XML is verbose and the browser is the primary messenger, the binding choice affects both security and user experience.
Used primarily for SAML Requests. The XML is Deflated, Base64-encoded, and appended as a query parameter to the URL. This makes it easy for the browser to move the user to the IdP.
💡 Redirect bindings are unsuitable for large responses because URLs have character limits in most browsers.
The terminal command shows the typical pipeline for analyzing a Redirect binding: Base64 decode followed by inflation (zcat/gzip) to reveal the raw XML.
SAML Responses are almost always sent via HTTP POST. This prevents the assertion from being leaked into server logs or browser history, which happens with Redirects.
<form method="POST" action="https://sp.example.com/acs">
<input type="hidden" name="SAMLResponse" value="PHSdW..." />
<input type="submit" value="Continue" />
</form>
<script>document.forms[0].submit();</script>The HTML above is the 'Auto-submit form.' The IdP sends this to the browser; the browser then POSTs the Base64-encoded XML assertion directly to the SP's Assertion Consumer Service (ACS).
| Binding | Direction | Transport | Security Note |
|---|---|---|---|
| HTTP Redirect | SP $ o$ IdP | URL Parameter | Leaks in logs/history |
| HTTP POST | IdP $ o$ SP | Form Body | Hides data from URL |
| Artifact | IdP $ o$ SP | Reference ID | Most secure, requires back-channel |
| SOAP | Direct | XML over HTTP | Used for backend synchronization |
To avoid sending a large XML assertion through the browser entirely, the Artifact binding sends a small 'Reference ID' (the artifact). The SP then connects directly to the IdP over a secure back-channel to exchange the artifact for the real assertion.
Artifact bindings are harder to implement because they require a stateful exchange and network connectivity between the two servers.
Verify exercises to earn ★ 190 XP and unlock next lab level.