Security Assertion Markup Language (SAML) 2.0 is an XML-based framework standardized by OASIS for exchanging authentication and authorization data between identity providers and service providers. SAML enables federated identity and single sign-on (SSO) by allowing users to access multiple applications across organizational boundaries with a single set of credentials.
How It Works
SAML operates through a four-layer architecture that coordinates authentication between identity providers and service providers. According to the OASIS SAML 2.0 specifications, the framework comprises four fundamental layers:
- Assertions (XML documents containing statements about authenticated users)
- Protocols (request-response message exchanges for obtaining assertions)
- Bindings (transport mechanisms including HTTP Redirect, HTTP POST, HTTP Artifact and SOAP)
- Profiles (complete implementation specifications for specific use cases, such as the Web Browser SSO Profile)
In a typical Web Browser SSO flow, a user attempts to access a protected resource at a service provider. The service provider generates an authentication request and redirects the user’s browser to the identity provider with this request. After the identity provider authenticates the user, it generates a signed SAML response containing assertions about the user’s identity and attributes. The browser posts this response back to the service provider, which validates the digital signature, checks validity conditions and grants access to the requested resource.
SAML messages require cryptographic protection through XML digital signatures and XML encryption. Production implementations must use X.509 certificates of at least 2048 bits minimum (1024-bit certificates are deprecated and should not be used) and signature algorithms of SHA-256 or stronger, as well as validate all incoming assertions against strict security criteria, including issuer verification, timestamp validation and audience restriction checks.
Why This Matters for Modern Enterprises
SAML remains the dominant protocol for browser-based enterprise single sign-on for human users, particularly for workforce access to legacy applications and browser-based enterprise systems. Organizations deploying hybrid cloud architectures typically use SAML for human user access to existing identity infrastructure, including Active Directory, Okta, Microsoft Entra ID and other enterprise identity providers.
SAML was designed specifically for browser-based human user authentication through HTTP redirect and POST bindings that transmit assertions through the user’s browser as an intermediary. According to the OASIS SAML 2.0 Profiles Specification, this architectural design makes SAML suitable for scenarios where users interact with web applications through browsers. For workload-to-workload authentication in cloud-native environments, organizations typically employ different protocols such as OIDC-based token exchange protocols (RFC 8693) or SPIFFE/SPIRE architectures designed specifically for machine identities, which support direct machine-to-machine communication without human browser interaction.
The protocol addresses regulatory compliance requirements by providing auditable authentication trails, centralized access control and standardized federation capabilities across organizational boundaries. According to NIST SP 800-63C (Federation and Assertions), three Federation Assurance Levels specify distinct security requirements: FAL1 defines bearer assertions with basic protections; FAL2 specifies bearer assertions protected by proof-of-possession mechanisms; and FAL3 requires cryptographically verified assertions with strong key management for government and high-security implementations.
Common Challenges With SAML
Identity and access management complexity: SAML federation typically requires metadata exchange between identity providers and service providers, involving X.509 certificate management, trust relationship configuration and attribute-mapping coordination. According to the OASIS SAML 2.0 Metadata Specification, organizations deploying SAML across multiple service providers often face scaling challenges with bilateral configuration and testing requirements for each new integration.
Session management and state requirements: SAML implements session-based authentication with validity periods typically ranging from 5 to 60 minutes, requiring stateful session management that conflicts with stateless microservices design patterns. The Single Logout (SLO) protocol requires coordinating logout requests across all participating service providers, creating distributed state management challenges. According to the OASIS SAML 2.0 Profiles Specification, SAML provides no built-in automatic credential rotation mechanism and requires substantial custom engineering to meet cloud-native security requirements for credentials that rotate automatically every few seconds or minutes.
Mobile and API architecture limitations: The HTTP Redirect and HTTP POST bindings depend on browser intermediaries to relay authentication messages, making SAML architecturally incompatible with native mobile applications, RESTful APIs and serverless functions that require direct programmatic authentication without user interaction.
Security vulnerability surface: XML-based protocols expose organizations to XML Signature Wrapping (XSW) attacks exploiting canonicalization weaknesses, XML External Entity (XXE) attacks if XML parsers aren’t hardened and replay attacks if assertion timestamps aren’t strictly validated. Each SAML implementation requires specialized security expertise to configure signature validation, encryption and assertion processing correctly.
FAQ
You Have Questions?
We Have Answers.
What is the difference between SAML, OAuth 2.0 and OpenID Connect?
SAML, an XML-based framework from OASIS, enables federated identity and SSO across organizational boundaries. OAuth 2.0 provides authorization capabilities for delegated resource access, enabling applications to obtain limited resource access tokens without exposing user credentials. OpenID Connect extends OAuth 2.0 by adding an identity layer with standardized authentication through JSON Web Tokens. Security teams should use SAML for browser-based enterprise SSO with legacy systems, OAuth 2.0 for API authorization scenarios and OpenID Connect for modern authentication scenarios, including mobile applications, APIs and cloud-native architectures.
Can SAML be used for workload identity and machine-to-machine authentication?
SAML was designed for browser-based human user authentication, where HTTP redirect and POST bindings transmit assertions through browsers as intermediaries. Microservices, API endpoints and automated workloads lack the capability to initiate browser redirects, interact with login pages or maintain session cookies. Modern workload authentication relies on purpose-built protocols, including SPIFFE/SPIRE for cryptographic workload identity, OIDC token exchange (RFC 8693) for API authentication and cloud provider workload identity federation using short-lived tokens with automatic rotation.
How do major cloud providers implement SAML support?
AWS IAM supports SAML for human user federation to the AWS Management Console and positions OIDC as the primary protocol for workload scenarios through AssumeRoleWithWebIdentity. Microsoft Azure Entra ID (formerly Azure AD) implements SAML for enterprise application SSO but exclusively uses OIDC for workload identity federation with no SAML support for machine identities. Google Cloud Platform supports both SAML and OIDC for workload identity federation but explicitly recommends OIDC for new implementations, reserving SAML for legacy system compatibility.
What are SAML assertions, and how are they validated?
SAML assertions are XML documents containing statements about authenticated users, including authentication context (how and when the user was authenticated), attributes (user properties like email, role, department), and authorization decisions (access permissions). According to the OASIS SAML 2.0 Core specification, service providers validate assertions by verifying the XML digital signature using XMLDSig with the identity provider’s X.509 certificate, checking that the assertion hasn’t expired through NotBefore and NotOnOrAfter timestamps, confirming the Audience restriction matches the service provider’s entity ID and ensuring the assertion hasn’t been replayed by tracking unique assertion IDs. Production deployments require SHA-256 or stronger signature algorithms per Okta security guidelines and must reject assertions with weak cryptographic protections. The W3C XML Signature Syntax and Processing specification defines the cryptographic validation mechanisms used for SAML assertion integrity verification.