SAML (Security Assertion Markup Language)
The XML-based federation standard behind most enterprise SSO — verbose, battle-tested, and full of signature-validation traps that became real CVEs.
Last reviewed: July 25, 2026
What is SAML?
SAML (Security Assertion Markup Language) is the XML standard that powers a large share of enterprise SSO. The flow: a user hits an application (the service provider), gets redirected to the identity provider, authenticates, and returns carrying a signed XML assertion vouching for their identity and attributes. The SP validates the signature against the IdP’s certificate and grants access. It predates and coexists with OIDC — SAML dominates legacy enterprise and B2B SaaS integrations; OIDC (JSON, OAuth-based) dominates new consumer and mobile builds.
Why it persists despite the XML
SAML is verbose, XML-namespaced, and unpleasant to hand-implement — and utterly entrenched, because two decades of enterprise apps, HR systems, and B2B integrations speak it, and IdPs support it universally. For connecting an enterprise workforce IdP to a SaaS vendor, SAML remains the path of least resistance. New greenfield services reach for OIDC; nobody rips working SAML out.
The security minefield — use a library
SAML’s history is a catalog of signature-validation vulnerabilities, and they’re subtle enough that rolling your own parser is professional malpractice. The classics: XML Signature Wrapping (attacker restructures the document so the signature validates against a benign element while the app reads an injected malicious one), signature-exclusion attacks (strip the signature; does the SP still accept it?), and XML canonicalization ambiguities. Real products shipped auth bypasses from each. The mandatory disciplines: use a maintained, audited SAML library; validate signatures over the right elements; check assertion conditions (audience, NotOnOrAfter expiry, recipient); and prevent replay.
What people get wrong
- Hand-parsing SAML XML — the direct road to a signature-wrapping CVE with your name on it.
- Skipping condition checks: an assertion valid for another SP or long expired must be rejected.
- Confusing SAML and OIDC scope — SAML federates identity; it isn’t OAuth, and bolting API authorization onto it is a mismatch.
Primary source: OASIS — SAML 2.0 specifications
SAML vs. OAuth/OIDC
SAML and OAuth 2.0/OpenID Connect solve related but distinct problems and are often confused: SAML is primarily designed for enterprise single sign-on scenarios, using XML-based assertions exchanged between an identity provider and a service provider, and predates OAuth by several years. OpenID Connect, built as a layer on top of OAuth 2.0, has become the more common choice for newer, especially consumer-facing and API-driven applications, using JSON-based tokens (JWTs) rather than XML, which tend to be simpler to work with in modern web and mobile development. SAML remains dominant in enterprise environments with established identity infrastructure (Active Directory Federation Services, Okta, Azure AD), while OIDC has become the default choice for new application development, meaning many organizations end up needing to support both standards simultaneously to serve different integration needs.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.