Quiz Entry - updated: 2026.10.22
How do the HTTP Redirect and HTTP POST bindings differ, and why is the IdP's response usually sent with POST?
Redirect puts the deflated, Base64-encoded message into a URL and is limited by URL length, so it suits small requests; POST carries the message in an auto-submitted HTML form, so it can carry large signed assertions.
| HTTP Redirect | HTTP POST | |
|---|---|---|
| Where the message sits | URL parameter SAMLRequest / SAMLResponse |
Hidden form field, auto-submitted by a script |
| Encoding | DEFLATE, then Base64, then URL-encoded | Base64 |
| Size | Limited by browser and server URL limits | Practically unlimited |
| Signature | Separate Signature and SigAlg URL parameters |
XML Signature inside the message |
| Leaks into | Browser history, proxy and server logs (URLs are logged) | Not into URLs |
| Typical use | SP's <AuthnRequest> to the IdP |
IdP's <Response> with the assertion |
A signed assertion with attributes and an embedded certificate easily runs to several kilobytes, too big for a reliable URL and too sensitive to end up in logs. So the classic combination is request by Redirect, response by POST.
Both bindings can carry a RelayState value: an opaque token the SP sends along and gets back unchanged, typically to remember which page the user originally requested.
Go deeper:
SAML 2.0: HTTP Redirect Binding (Wikipedia) — how the deflate and encode steps produce the redirect URL.- SAML 2.0: HTTP POST Binding (Wikipedia) — the auto-submitting HTML form that carries the response.