What is SAML?
Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). Developed by OASIS, SAML 2.0 is the dominant version and is widely used for enterprise Single Sign-On, enabling users to authenticate once with an IdP and access multiple SPs without re-entering credentials.
SAML works by having the identity provider issue digitally signed XML assertions that contain the user's identity, attributes, and authorization decisions. These assertions are consumed by service providers to grant access. SAML has been the backbone of enterprise SSO since its ratification in 2005, and it remains deeply embedded in legacy enterprise applications, SaaS platforms, and government systems.
While newer protocols like OpenID Connect have gained traction for modern web and mobile apps, SAML continues to dominate in enterprise environments where established integrations and regulatory requirements favor its mature, battle-tested approach. Most identity platforms including Okta, Microsoft Entra ID, Ping Identity, and OneLogin support both SAML and OIDC.
How SAML Works
SAML defines three roles: the principal (user), the identity provider, and the service provider. The most common flow is the SP-initiated SSO flow:
- User accesses the service provider -- The user navigates to an application (e.g., Salesforce, Workday) that requires authentication.
- SP generates AuthnRequest -- The SP creates an XML authentication request and redirects the user's browser to the IdP's SSO URL, passing the AuthnRequest via HTTP Redirect or HTTP POST binding.
- IdP authenticates the user -- If the user has no active session at the IdP, the IdP prompts for credentials (and potentially MFA). If a session exists, this step is skipped.
- IdP creates SAML assertion -- The IdP generates a signed XML assertion containing the user's identity (NameID), attributes (email, roles, groups), and conditions (validity period, audience restriction).
- Assertion delivered to SP -- The IdP sends the assertion to the SP's Assertion Consumer Service (ACS) URL, typically via HTTP POST through the user's browser.
- SP validates assertion -- The SP verifies the XML signature using the IdP's certificate, checks the audience restriction and time validity, and extracts user attributes.
- SP grants access -- The SP creates a local session for the user and grants access based on the asserted identity and attributes.
SAML in Practice
SAML 2.0 is supported by virtually every enterprise SaaS application. Salesforce, Workday, ServiceNow, Box, AWS, and hundreds of other platforms accept SAML assertions for SSO. Cloud identity providers like Okta, Microsoft Entra ID, Ping Identity, and Google Workspace serve as SAML IdPs, managing authentication for thousands of connected applications.
Configuring a SAML integration involves exchanging metadata between IdP and SP -- the IdP provides its entity ID, SSO endpoint URL, and signing certificate, while the SP provides its entity ID and ACS URL. Many platforms support metadata exchange through XML files or URLs, automating much of the configuration.
In government and healthcare, SAML remains the preferred protocol due to its extensive tooling, well-understood security properties, and longstanding compliance track record. The US government's Login.gov identity service, for example, supports SAML for federal agency integration.
Common Misconceptions
"SAML is outdated and should be replaced everywhere." While OpenID Connect is preferred for modern web and mobile applications, SAML remains the right choice for enterprise SSO integrations with legacy applications that only support SAML. Migrating working SAML integrations to OIDC without a concrete benefit introduces unnecessary risk. "SAML and OAuth solve the same problem." SAML primarily handles authentication and SSO -- proving who the user is. OAuth 2.0 handles authorization -- granting access to resources. While there is overlap (both can enable SSO), they serve fundamentally different primary purposes and are often used together. "SAML assertions are inherently secure because they use XML signatures." SAML assertions are signed but not encrypted by default. Without encryption, assertion contents are visible to intermediaries. SAML also has a history of XML signature wrapping vulnerabilities. Implementations must use well-tested libraries and validate assertions rigorously.Key Standards & RFCs
- SAML 2.0 Core (OASIS Standard) -- Defines the assertion format, protocols, and bindings for SAML-based SSO.
- SAML 2.0 Bindings -- Specifies how SAML messages are transported (HTTP Redirect, HTTP POST, HTTP Artifact, SOAP).
- SAML 2.0 Profiles -- Defines use-case-specific message flows, including Web Browser SSO Profile and Single Logout Profile.
- SAML 2.0 Metadata -- Standardizes the exchange of configuration information between IdPs and SPs.
- NIST SP 800-63C -- Federation assurance levels relevant to SAML-based identity federation deployments.
Frequently Asked Questions
What is SAML?
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider, primarily used for enterprise Single Sign-On.
How does SAML work?
The service provider redirects the user to the identity provider for authentication. The IdP authenticates the user and sends a signed XML assertion back to the SP, which validates it and grants access.
What is SAML used for?
SAML is primarily used for enterprise SSO, enabling employees to access multiple SaaS applications (Salesforce, Workday, AWS) with a single login through a centralized identity provider.
What are the benefits of SAML?
SAML provides standardized SSO across enterprise applications, reduces password management burden, enables centralized access control and audit logging, and is supported by virtually all enterprise SaaS platforms.