Security Assertion Markup Language (SAML) explained
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between security domains. It enables Single Sign-On (SSO) by allowing users to authenticate once with an Identity Provider (IdP) and access multiple Service Providers (SPs) without re-entering credentials.
SAML is XML-based and is primarily used in enterprise environments to federate identity across web applications, SaaS platforms, and organizational boundaries.
The current version, SAML 2.0, was standardized by OASIS in 2005 and remains a foundational protocol for browser-based enterprise SSO.
Core SAML components
Every SAML authentication flow involves three primary roles:
Principal
The end user attempting to access an application (e.g., an employee, partner, or customer).
Identity Provider (IdP)
The system that authenticates the user and issues security assertions. Examples include Okta, Microsoft Entra ID, and Ping Identity.
Read our glossary entry on IdP.
Service Provider (SP)
The application or service the user wants to access. The SP relies on the IdP to verify the user’s identity.
Key SAML terms
SAML assertion
A digitally signed XML document issued by the IdP containing statements about an authenticated user.
SAML response
The message sent from the IdP to the SP containing one or more assertions.
SAML request (authentication request)
A request generated by the SP asking the IdP to authenticate the user.
SAML metadata
Configuration data exchanged between IdP and SP to establish trust. It includes public keys, entity identifiers, and endpoint URLs.
SAML token
An informal term often used interchangeably with “SAML assertion.”
What is SSO in the context of SAML?
Single Sign-On (SSO) allows users to log in once and access multiple applications without being prompted for credentials again.
With SAML-based SSO:
- The user authenticates with the Identity Provider.
- The IdP sends a signed assertion to the Service Provider.
- The SP validates the assertion and grants access.
Users only enter credentials at the IdP. Applications never directly handle user passwords, which reduces credential exposure and centralizes authentication control.
How SAML works (high-level flow)
SAML uses the browser as an intermediary to exchange messages between IdP and SP via HTTP Redirect or HTTP POST bindings.
Two common SAML flows exist:
1. SP-Initiated flow
This begins when a user attempts to access an application directly.
- User navigates to the SP.
- SP detects no session and sends a SAML authentication request to the IdP.
- The IdP authenticates the user.
- The IdP issues a signed SAML assertion.
- The assertion is returned to the SP through the browser.
- The SP validates the assertion and creates a session.
This is the most common enterprise SSO pattern.
2. IdP-Initiated flow
This begins at the Identity Provider’s portal.
- User logs into the IdP dashboard.
- User selects an application.
- The IdP sends a SAML assertion directly to the SP.
- The SP validates the assertion and establishes a session.
This approach is common when organizations provide centralized application portals.
What is a SAML assertion?
A SAML assertion is a structured XML statement issued by the Identity Provider that conveys security information about a user.
SAML 2.0 defines three types of statements:
Authentication statement
Confirms the user authenticated successfully, including authentication method and timestamp.
Attribute statement
Contains user attributes such as email, department, role, or group membership.
Authorization decision statement
Indicates whether a user is permitted to perform a specific action (less commonly used).
Assertions also include validation elements:
- Issuer – The IdP that created the assertion
- Audience – The intended Service Provider
- Conditions – Usage restrictions and replay protections
- Issue time and expiration – Time bounds limiting validity
Assertions are digitally signed to ensure integrity. Many implementations also encrypt them to protect sensitive attributes.
SAML authentication vs. authorization
Understanding this distinction is critical.
SAML authentication
Verifies identity. The IdP confirms “Who is this user?” and issues an authentication assertion.
SAML authorization
Determines permissions. The SP decides “What can this user access?” based on attributes, roles, and internal policies.
SAML primarily handles authentication and attribute sharing. Detailed authorization logic typically remains within the Service Provider or an access management system.
How to set up SAML authentication
What is SAML 2.0?
SAML 2.0 is the current major version of the standard. It consolidated earlier SAML specifications and identity federation profiles into a comprehensive framework for browser-based SSO.
Key capabilities include:
- Web-based SSO
- Single Logout (SLO)
- Standardized metadata exchange
- Attribute federation
- Cross-domain identity federation
SAML 2.0 remains widely supported by enterprise SaaS providers and government systems.
Common use cases
SAML is primarily used in enterprise and institutional environments:
Workforce SSO
Employees access multiple SaaS and internal applications through one corporate login.
B2B federation
External partners authenticate using their own IdP to access shared systems.
Government identity federation
Agencies establish trust relationships to allow cross-service access.
Education
Students and faculty authenticate once to access academic systems, email, and administrative portals.
Security benefits of SAML
SAML centralizes authentication at the Identity Provider, which offers several advantages:
- Passwords are never shared with Service Providers
- Multi-Factor Authentication (MFA) can be enforced centrally
- Conditional access policies can apply across applications
- Cryptographic signatures prevent assertion tampering
- Time-bound assertions reduce replay attack risk
Because authentication occurs at a trusted IdP, compromised Service Providers do not expose user credentials.
SAML vs. related standards
SAML is one of several identity federation and authorization standards.
SAML vs. OpenID Connect (OIDC)
- SAML uses XML and is optimized for enterprise web SSO.
- OIDC uses JSON and builds on OAuth 2.0, often preferred for modern web and mobile applications.
SAML vs. OAuth 2.0
- SAML focuses on authentication and identity federation.
- OAuth 2.0 focuses on delegated authorization (allowing applications to access resources on a user’s behalf).
SAML vs. LDAP
- LDAP is a directory protocol for storing and retrieving user data.
- SAML is a federation protocol for web-based SSO.
In many architectures, an IdP authenticates users against LDAP or Active Directory, then issues SAML assertions to cloud applications.
