SAML 2.0 in One Diagram

SAML 2.0 is often misunderstood as a single protocol. It is not. It is a framework comprising profiles (definitions of use cases) and bindings (mechanisms for transporting messages). For engineers, the most critical interaction is the Web Browser SSO Profile using the HTTP Redirect and HTTP POST bindings. This diagrammatic walkthrough explains the mechanism, the data flow, and how it differs from modern OpenID Connect (OIDC).

The Actors

A comprehensive saml tutorial begins by defining the three actors before tracing the packet flow:

1. User Agent (UA): The user’s browser. It carries state (cookies, URL parameters) but holds no credentials itself.
2. Service Provider (SP): The application the user wants to access (e.g., Salesforce, Slack). It trusts assertions from the IdP.
3. Identity Provider (IdP): The authority that verifies the user’s identity (e.g., Okta, Azure AD). It issues signed SAML Assertions.

The SSO Flow Mechanism

The following sequence describes the Unsolicited or Solicited Web Browser SSO flow. We will trace the Solicited flow, where the SP initiates the request.

Step 1: The SP Redirects to the IdP

When Alice tries to access app.example.com, the SP detects she has no valid session. The SP generates a SAML AuthnRequest and redirects the browser to the IdP.

This message is compressed using DEFLATE (RFC 1951) and encoded in Base64, then URL-encoded, to fit within HTTP GET parameter limits. This is the HTTP Redirect Binding.

GET https://idp.example.com/sso/redirect?SAMLRequest=PHNhbWxwOkF1dGhO... HTTP/1.1
Host: idp.example.com

• SAMLRequest: The encoded XML document containing the request details (e.g., Issuer, RequestedAuthnContext).

Step 2: User Authentication at the IdP

The IdP receives the request. It checks if Alice is already authenticated. If not, it renders a login form. Alice enters her credentials. The IdP validates them against its directory (LDAP, Active Directory, etc.).

Step 3: The IdP Posts the SAML Response

Once authenticated, the IdP constructs a SAML Response (containing one or more Assertions). This message contains:

• Subject: Who is authenticated (e.g., alice@example.com).
• Conditions: When the assertion is valid (notBefore, notAfter).
• Attributes: Optional data (email, role).
• Signature: An XML Signature (ds:Signature) covering the entire response.

Crucially, this response is sent via HTTP POST to the SP’s Assertion Consumer Service (ACS) URL.

<form method="POST" action="https://app.example.com/sso/acs">
  <input type="hidden" name="SAMLResponse" value="PHNhbWxyZ..."/>
  <input type="hidden" name="RelayState" value="random-state-token"/>
  <button type="submit">Submit</button>
  <script>document.forms[0].submit();</script>
</form>

• SAMLResponse: The Base64-encoded XML assertion.
• RelayState: An opaque token allowing the SP to restore the original context (e.g., the page Alice originally requested).

Step 4: SP Validation and Session Creation

The SP receives the POST request. It must now perform three critical validations:

1. Verify the Signature: The SP uses the IdP’s public certificate (fetched from metadata) to verify the ds:Signature. This ensures the message originated from the IdP and was not tampered with.
2. Check Conditions: Is the assertion within the valid time window? Is the Audience URI in the assertion matching the SP’s entity ID?
3. Create Session: If valid, the SP creates a local session for Alice.

Why HTTP POST for the Response?

You might wonder why the initial request uses GET (Redirect) but the response uses POST.

• Size Limits: SAML Assertions can be large, especially if they contain many attributes or a long signature. HTTP GET URLs have strict length limits (often ~2KB in some browsers/servers). HTTP POST bodies do not.
• Security: GET parameters are logged in server access logs, browser history, and proxy logs. POST data is not stored in these locations by default, reducing exposure of sensitive assertion data.

Cryptography: XML Signature vs. JWT

A saml tutorial on SAML 2.0 vs. OIDC must address the cryptographic differences.

• OIDC (JWT): Uses JSON Web Tokens (JWT) signed with JSON Web Signatures (JWS). The signature is compact, URL-safe, and easy to parse in JavaScript.
• SAML (XML): Uses XML Signature (ds:Signature). This is a verbose, XML-based standard that supports complex canonicalization and transformation rules. It relies on X.509 certificates directly embedded in the SAML metadata or exchanged out-of-band. In practice, XML Signature validation requires careful handling of canonicalization methods (such as Exclusive Canonicalization) to ensure the signature covers exactly the intended elements, avoiding hash collisions or injection attacks that simpler formats might miss.

This makes SAML heavier to parse and more error-prone in client-side environments (like pure JavaScript SPs), which is why OIDC has largely replaced SAML for consumer-facing apps.

SAML 2.0 vs. OIDC: A Comparison

A saml tutorial typically contrasts these protocols using the following breakdown:

Conclusion

A saml tutorial concludes by summarizing the trade-offs. SAML 2.0 remains the backbone of enterprise identity federation. Its strength lies in its explicit separation of profiles and bindings, allowing flexibility in deployment. However, its XML-centric design and verbosity make it less suitable for modern, mobile-first, or client-side applications where OIDC’s JWT-based simplicity shines.

For engineers, mastering SAML means understanding the HTTP POST return of the SAML Response and the rigorous XML Signature validation process. Once you grasp that flow, the rest of the SAML ecosystem becomes a matter of metadata management and attribute mapping.