SAML
Also known as: SAML 2.0, SSO, SAML assertion, IdP, SP, enterprise SSO
SAML (Security Assertion Markup Language) is the older enterprise standard for Single Sign-On.
When you log in via your company's identity provider and get redirected to a business application, SAML is often the protocol exchanging authentication credentials behind the scenes. It predates modern REST APIs and uses XML and browser redirects.
SAML, explained at three levels
At home
SAML is the technology behind many corporate 'single sign-on' logins. When you click a link to your company's HR software and it automatically logs you in without asking for a password, SAML passed proof of your identity from your company's login system to the HR software.
At work
Enterprise software uses SAML to let employees log in using their company credentials. Instead of creating separate accounts in every SaaS tool, IT connects each tool to the company's identity provider (Microsoft Entra ID, Okta) via SAML. Login works automatically for authenticated employees.
At home
SAML involves three parties: the User, the Identity Provider (IdP, your company's Okta or Microsoft Entra ID), and the Service Provider (SP, the SaaS app). The IdP issues a signed XML SAML assertion containing user attributes (email, name, groups). The browser carries this assertion to the SP, which validates the signature and logs the user in.
At work
SAML configuration requires exchanging XML metadata between IdP and SP: the IdP metadata contains the signing certificate and SSO URL; the SP metadata contains the entity ID and assertion consumer service URL. SP-initiated flow starts at the application (most common); IdP-initiated flow starts from the identity provider dashboard. Attribute mapping determines which SAML attributes map to user fields in the SP.
At home
SAML assertions are XML documents signed with RSA or DSA. The AuthnStatement records when and how the user authenticated. AttributeStatements carry user properties. The assertion is encoded in Base64 and passed via an HTML form POST (to avoid URL length limits). The SP must validate the assertion's signature, timestamps (NotBefore, NotOnOrAfter), and audience restriction.
At work
SAML's XML signature verification is complex and historically error-prone: vulnerabilities like XML signature wrapping attacks have affected multiple SAML implementations. Security audit checklist: validate the entire signed element (not just a subset), enforce audience restrictions, check NotOnOrAfter with clock skew tolerance, and validate certificates against known-good IdP certs (not self-reported entity IDs). SLO (Single Logout) propagates logout across all SP sessions but is poorly implemented by many SPs.
Real-world examples
At home
Marcus clicks 'Open Workday' in his company's Okta dashboard. Okta generates a SAML assertion signed with its private key and posts it to Workday. Workday validates the signature against Okta's stored certificate and logs Marcus in as his user account: no password entry.
At work
Lena's company IT team onboards a new HR tool. They configure SAML by downloading the tool's SP metadata, uploading it to Okta, and providing the Okta IdP metadata URL to the vendor. After attribute mapping (linking 'email' attribute to the tool's 'User Login' field), employees can log in with their company credentials.
How it compares
| feature | SAML | OIDC |
|---|---|---|
| Token format | XML assertion | JSON (JWT) |
| Transport | Browser redirect / form POST | REST API (JSON) |
| Mobile-friendly | Poor (browser-dependent) | Yes (API-based) |
| Enterprise adoption | Very high (legacy apps) | High (modern apps) |
| Configuration | XML metadata exchange | JSON discovery document |
| Created | 2002/2005 | 2014 |
For analysts
SAML is directly relevant when onboarding new SaaS tools to corporate SSO: BAs leading vendor evaluations should ask whether the tool supports SAML 2.0 (standard) or requires a separate login, which creates an access management burden.
History & origin
SAML 1.0 was developed by OASIS in 2002 and SAML 2.0 released in 2005, targeting enterprise web application SSO at a time when XML web services were the standard. SAML became the dominant enterprise SSO protocol, embedded in almost every major SaaS application (Salesforce, Workday, ServiceNow). The rise of mobile apps and REST APIs favoured OIDC's JSON-based approach for new development, but SAML remains deeply entrenched in enterprise environments with large installed bases of legacy integrations.