Glossary
SAML
Security Assertion Markup Language
By Buğra SözeriPublished Updated
SAML (Security Assertion Markup Language) is an XML-based single-sign-on (SSO) standard published by OASIS in 2005. Used heavily in enterprise B2B integrations — Okta, Ping Identity, Microsoft AD FS, Google Workspace, every SaaS that sells to large companies.
The model: an Identity Provider (IdP, e.g. Okta) authenticates the user. The user lands at a Service Provider (SP, e.g. Salesforce) with a signed SAML assertion proving who they are. The SP verifies the signature against the IdP’s public key and trusts the claim.
SAML vs OAuth2/OIDC: SAML is older, XML-based, designed for enterprise SSO. OAuth/OIDC are JSON-based, designed originally for delegated authorisation (“allow this app to read my Gmail”) and later extended to authentication (OIDC). New enterprise integrations increasingly use OIDC; existing enterprise SaaS often still requires SAML because customers’ IdPs require it.
The XML signature spec SAML uses is notoriously footgun-y — XML signature wrapping attacks exist on many implementations. Modern libraries (e.g., python-saml, OneLogin’s) handle this correctly by default; rolling your own is a bad idea.
SAML bindings — how the assertion travels: SAML defines several transport bindings. HTTP Redirect compresses and base64-encodes the request into a URL query string (limited by browser URL length); HTTP POST sends a base64-encoded blob in a form auto-submitted via JavaScript (the most common in 2026); HTTP Artifact passes a short reference token that the SP exchanges out-of-band for the full assertion. POST is the modern default because it handles assertion sizes that comfortably blow past URL limits and avoids leaking the assertion into proxy logs. The assertion itself is wrapped in base64 and signed with SHA-256.
Operational pitfalls in enterprise SAML rollouts: clock skew between IdP and SP (assertions have a 5-minute validity window by default — a misconfigured server time breaks login for everyone), certificate rotation (the IdP’s signing cert expires every 1-3 years and must be rotated before that date or all SSO fails simultaneously), and NameID format mismatches (the IdP issues emailAddress but the SP expects persistent opaque IDs). The classic enterprise war story is an SSO outage on a Monday morning because the IdP cert silently expired Sunday night and nobody owned the renewal. Reference: OASIS SAML 2.0 Core specification.
Worked example
An employee clicks “Sign in with company SSO” on app.example.com. The SP (Service Provider) generates a SAML <AuthnRequest> XML document and POSTs it to the IdP at sso.acme.com/saml. The IdP authenticates the user (probably via password + WebAuthn) and returns a SAML <Response> containing an <Assertion> with: the user’s email (NameID), group memberships (AttributeStatement), validity window (NotBefore / NotOnOrAfter ~5 minutes), and audience restriction (must be exactly app.example.com). The XML is signed with the IdP’s RSA-2048 key using SHA-256. The browser auto-POSTs this base64-encoded blob back to app.example.com/saml/acs. The SP verifies the signature against the IdP’s pre-shared public certificate, checks the validity window and audience, extracts the email, and creates a local session. The whole exchange is two HTTP redirects and is invisible to the user beyond the IdP’s login screen.
When and why it matters
If you sell B2B SaaS, SAML support is the gating feature for enterprise sales — most companies above 500 employees mandate that all SaaS access go through their IdP for offboarding control (when an employee leaves, the IdP revokes their session and they lose access to every connected SaaS at once). Modern security incidents at SaaS vendors (Okta 2022, Cloudflare 2023) trace to the SAML or session token layer rather than passwords specifically because SSO is the credential of record. The defensive checklist for any SAML implementation: validate the signature on every assertion (not just the response wrapper), validate InResponseTo to prevent replay, validate audience and recipient, enforce the time window strictly, and store the IdP certificate fingerprint out-of-band so a compromised metadata URL can’t silently swap the trusted key. Reference: OWASP SAML Security Cheat Sheet.
Frequently asked questions
- What is SAML?
- SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorisation data between an identity provider (IdP) and a service provider (SP), enabling single sign-on (SSO) in enterprise environments.
- How does SAML work in practice?
- A user tries to access Salesforce (SP), which redirects them to their company's Active Directory Federation Services (IdP). The user authenticates once; the IdP sends a signed XML assertion to Salesforce confirming identity and group memberships, and the user is logged in without re-entering credentials.
- What is the difference between SAML and OAuth/OIDC?
- SAML is an older XML-based protocol designed for enterprise SSO between organisations. OAuth 2.0/OIDC is a newer JSON/REST-based approach used predominantly in consumer apps and APIs. SAML is still dominant in enterprise B2B integrations; OIDC has largely displaced it for new consumer-facing web and mobile applications.
Related
Published May 15, 2026 · Last reviewed May 31, 2026