What is SAML (Security Assertion Markup Language)?

What is SAML?

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). Standardized in 2005, SAML 2.0 is the dominant enterprise SSO protocol — when a SaaS app says "SSO supported," they almost always mean SAML 2.0. Slack, Salesforce, AWS, Workday, Zoom, and thousands of other enterprise applications all support SAML.

The core mechanic: when a user tries to log in to a Service Provider (your app), the SP redirects them to the Identity Provider (Okta, Microsoft Entra ID, Google Workspace, Auth0). The IdP authenticates the user (verifies password, enforces MFA), then issues a digitally signed XML document called a SAML assertion. The user's browser carries this assertion back to the SP, which verifies the signature against the IdP's public key and trusts the user is who the IdP says they are.

The SAML flow (SP-initiated, the common case)

1. User accesses the SP (e.g. https://app.example.com) and clicks "Sign in with SSO".
2. SP redirects to IdP with a SAML AuthnRequest — an XML message saying "please authenticate this user for me." The redirect goes through the user's browser via HTTP-Redirect or HTTP-POST binding.
3. IdP authenticates the user. Username + password, then MFA, possibly conditional access policies. If the user already has an active IdP session, this step is invisible.
4. IdP generates a SAML Response. An XML document containing one or more assertions with claims about the user (name, email, group memberships), digitally signed with the IdP's private key.
5. IdP redirects the user's browser back to the SP's ACS URL (Assertion Consumer Service) with the signed Response, typically as a base64-encoded HTTP POST body.
6. SP validates the Response. Checks the signature against the IdP's published public certificate, validates timestamps (NotBefore/NotOnOrAfter), checks the audience matches its expected entity ID. If everything checks out, SP creates a local session for the user.

The user typically experiences this as a single browser redirect — they click "Sign in," briefly see the IdP page (or not), and land back in the app already authenticated. Total elapsed time: 1-3 seconds.

What's in a SAML assertion (the XML payload)

A typical SAML 2.0 Response contains:

• Issuer: Which IdP signed this — used to look up the right public key.
• Signature: The XML digital signature over the Response (or the Assertion within it).
• Subject: Identifies the user, typically as a NameID (email, UUID, or transient/persistent identifier).
• Conditions: NotBefore and NotOnOrAfter timestamps that bound when the assertion is valid (usually a 5-minute window).
• AudienceRestriction: Which SP this assertion is intended for. If the SP's entity ID doesn't match, reject.
• AuthnStatement: When and how the user authenticated (password, MFA, etc.).
• AttributeStatement: Custom attributes the IdP includes — email, first/last name, group memberships, department, manager, employee ID. The SP uses these to provision and authorize the user.

Why SAML is verbose (and why it persists despite that)

SAML is famously complex: XML namespaces, X.509 certificates, multiple signing/encryption options, dozens of optional fields. Compared to JSON Web Tokens (JWT) used in OpenID Connect, a SAML message is 10-50× larger in bytes.

So why does SAML still dominate enterprise SSO?

• Network effect. Every major IdP and every enterprise SaaS already supports SAML. Switching costs are huge.
• Mature tooling. 20 years of libraries, debuggers, test IdPs. Procurement teams know how to evaluate SAML support.
• Enterprise habits. Buyers explicitly require SAML in RFPs. "OIDC-only" is a non-starter for most large procurement.
• Genuine security depth. SAML supports complex use cases (encrypted assertions, attribute encryption, multi-tier signing) that simpler protocols handle awkwardly.

For new integrations between modern systems, OpenID Connect (built on JWT and OAuth 2.0) is simpler and increasingly preferred. For enterprise SaaS, SAML is still required — most production systems support both.

Common SAML implementation gotchas

• Clock skew. SAML assertions have NotBefore and NotOnOrAfter timestamps. If the IdP's clock and SP's clock differ by more than the configured tolerance (usually 60-300 seconds), authentication fails. NTP-sync everything.
• Certificate rotation. SAML signatures use X.509 certificates that expire (typically 1-3 years). Failing to rotate before expiry takes down SSO at 03:00 on a Tuesday. Calendar reminders are mandatory; metadata exchange (auto-rotation) is rare in practice.
• Group claim mapping. The IdP sends groups in the assertion; the SP must map those to local roles. Misconfigured group mappings are the #1 source of "why am I not an admin?" tickets.
• SP-initiated vs IdP-initiated. Some SaaS apps support both; some only SP-initiated. IdP-initiated (user starts in Okta dashboard, clicks SP tile) is convenient but introduces security considerations — the SP must accept assertions it didn't request.
• NameID format. Different IdPs default to different NameID formats (email vs persistent UUID vs transient). The SP must agree on which to expect or matching breaks.
• Replay protection. SP must remember IDs of recently-validated assertions and reject duplicates. Without this, intercepted assertions can be replayed.

SAML vs OIDC vs OAuth 2.0

The three protocols often confused:

• SAML 2.0: XML-based authentication standard. Dominant in enterprise SSO. Verbose but robust.
• OAuth 2.0: Authorization framework — "can this app access this user's data?" Doesn't establish identity on its own.
• OpenID Connect (OIDC): Authentication layer built on OAuth 2.0. JSON-based, JWT tokens. Modern, simpler than SAML. Powers "Sign in with Google/Apple/Microsoft."

Practical guidance: implement OIDC for self-service / consumer signups (simpler, JSON-friendly); add SAML for enterprise customers (mandatory for many procurement teams).

FAQ: SAML

Is SAML still relevant in 2026?

Yes — for enterprise SSO, it's still the dominant standard. OIDC is gaining ground for new integrations and consumer auth, but SAML's enterprise install base means it'll be required for the foreseeable future. Plan to support both.

What's the difference between SAML and OAuth?

Different purposes. SAML is authentication-first ("who is this user?"). OAuth is authorization-first ("can this app access this user's resources?"). They're often combined — SAML for SSO, OAuth for API access. OIDC merges the two by adding identity claims to OAuth.

Why does SAML use XML when JSON is everywhere now?

Historical accident. SAML 2.0 was finalized in 2005, before JSON dominated the web. By the time JSON became the default, SAML's enterprise install base was too large to migrate. New protocols (OIDC) use JSON; SAML stays XML out of compatibility.

Is SAML secure?

Yes when implemented correctly. The protocol is well-specified and battle-tested. Most SAML breaches come from implementation bugs (signature validation flaws, replay attacks) rather than protocol weaknesses. Use a battle-tested SAML library; don't hand-roll the XML parsing.

How do I debug a SAML integration?

Tools: SAML-tracer Firefox extension (captures and decodes SAML messages), online SAML decoders (paste base64-encoded assertions, get readable XML), IdP debug logs (Okta, Auth0, Microsoft all expose detailed traces), and SP error pages with verbose mode enabled. Most SAML breakage is signature mismatch or clock skew — check those first.

What's SCIM and how does it relate to SAML?

SCIM (System for Cross-domain Identity Management) automates user provisioning between IdP and SPs. SAML handles authentication (login); SCIM handles "create this user when they're added to the IdP, delete them when they're removed." Together, SAML + SCIM is the gold standard for managed enterprise SaaS.

How LoadFocus relates to SAML SSO

LoadFocus supports SAML 2.0 SSO on Enterprise plans (alongside OIDC). For load testing apps that use SAML auth, our load testing supports OAuth flows for service-to-service tokens — the typical pattern is to use a service account with token exchange rather than browser-based SAML for synthetic traffic. API monitoring validates that SAML-protected endpoints respond correctly when triggered by automation.