What does the SAMLart value in the SAML HTTP-Artifact binding contain, and how is the real message fetched?

## A reference instead of a document The HTTP-POST and HTTP-Redirect bindings both put the whole SAML message into the user agent. The HTTP-Artifact binding, `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact`, does not. It hands the browser a short, opaque handle called an **artifact**, carried in a parameter named `SAMLart` — as a query parameter when the sender redirects, or as a form control when it posts. The recipient then goes and collects the actual message itself, over a direct connection the browser plays no part in. That single change of shape is what the binding is for. The message is never exposed to the user agent, never logged by an intermediary that records URLs, and never subject to a length ceiling, because the thing on the wire in front of the user is a fixed-size handle. ## What is inside the artifact The artifact's structure is defined as: ``` SAML_artifact := B64(TypeCode EndpointIndex RemainingArtifact) ``` For the type this branch cares about, `urn:oasis:names:tc:SAML:2.0:artifact-04`: - **`TypeCode := 0x0004`**, two bytes, naming the artifact format so the recipient knows how to read the rest. - **`EndpointIndex`**, two bytes, selecting which of the issuer's artifact resolution endpoints the recipient should call. A party that publishes several endpoints distinguishes them this way. - **`RemainingArtifact`**, which for this type is two 20-byte fields: - **`SourceID`** — the SHA-1 of the issuer's identification URL. It identifies *who* to ask, without spelling out a URL in the handle. - **`MessageHandle`** — 20 bytes taken from a cryptographically strong random sequence of at least 16 bytes. It identifies *which* message to ask for, and being unguessable is the whole of its security value. So the handle answers two questions and carries no content: which party holds the message, and which message it is. ## Redeeming it The recipient decodes the artifact, resolves `SourceID` and `EndpointIndex` to the issuer's artifact resolution endpoint, and sends a `<samlp:ArtifactResolve>` containing the artifact. That exchange runs on the synchronous SOAP binding, `urn:oasis:names:tc:SAML:2.0:bindings:SOAP` — a direct server-to-server request, not something the browser mediates. The issuer replies with an `<ArtifactResponse>` that wraps the real protocol message. Two consequences follow immediately: 1. **The back channel authenticates the parties to each other directly.** The requester is talking to the issuer's endpoint over its own connection, rather than believing something a browser handed it. 2. **An artifact is single-use.** An issuer that has resolved one does not resolve it again, so a URL captured from a browser's history or a proxy log redeems nothing when replayed. ## What it buys and what it costs | | HTTP-POST | HTTP-Artifact | |---|---|---| | What the browser carries | the whole base64 message | a fixed-size handle | | Round trips | one | two — the front-channel hop plus the resolution exchange | | Exposure to intermediaries | the message passes through the user agent | only the handle does | | Requires direct reachability | no | yes — the recipient must reach the issuer's endpoint | | Length pressure | none in practice | none | The cost is concentrated in that fourth row. HTTP-POST and HTTP-Redirect work between two parties that have no network path to each other at all, which is precisely why the Web Browser SSO profile leans on them. HTTP-Artifact needs an outbound connection from the recipient to the issuer, which means firewall rules, a reachable endpoint on both sides of an organisational boundary, and an availability dependency: if the resolution endpoint is down, the login fails at a point where the front channel already looked successful. ## Where it still appears It is the least-used of the three browser-facing bindings, and a candidate who has never met it is not deficient. It turns up where an organisation has decided the message must not traverse the user agent, where an intermediary logs full URLs and that is unacceptable, or where an existing integration predates a decision to standardise on POST. Recognising `SAMLart` on a URL and knowing that a second, invisible exchange must follow is the level of familiarity the material genuinely demands. The diagnostic signature is distinctive: the front channel completes, the user's browser lands on the recipient, and then the login fails with nothing in the browser to look at — because the failure happened on a connection the browser never saw.