Typically, the intent of the artifact binding is to reduce the flow of SAML messages through the browser itself. This could be due to browser restrictions (browsers that have limits on query string / POST payload size) or no support for JavaScript (for auto-submitted forms), or even to improve the security model of how the SAML messages are transported. By using artifacts, sensitive data carried through the SAML Assertion / Attribute Statement is not passed through the browser, so it can be hidden from the end user or attackers between your site and the end user. This confidential data would only be directly resolved between sites through a back channel lookup.
Section 3.6.2 of the SAML 2.0 Bindings specs summarizes it best:
The HTTP Artifact binding is intended for cases in which the SAML
requester and responder need to communicate using an HTTP user agent
as an intermediary, but the intermediary's limitations preclude or
discourage the transmission of an entire message (or message exchange)
through it. This may be for technical reasons or because of a
reluctance to expose the message content to the intermediary (and if
the use of encryption is not practical). Note that because of the need
to subsequently resolve the artifact using another synchronous
binding, such as SOAP, a direct communication path must exist between
the SAML message sender and recipient in the reverse direction of the
artifact's transmission (the receiver of the message and artifact must
be able to send a request back to the artifact
issuer). The artifact issuer must also maintain state while the
artifact is pending, which has implications for load-balanced
environments.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
