Security Assertion Markup Language (SAML) 2.0 is an XML-based protocol that enables identity federation between separate security domains to deliver Single Sign-On (SSO). SAML allows users to authenticate with an identity provider (IdP) once and then access multiple service providers (SPs) without needing to re-enter their credentials.

SAML 2.0 was ratified as an OASIS open standard in 2005. It remains widely used for enterprise and government identity federation, though OpenID Connect (OIDC) has become increasingly common for modern applications.

Example: When you log in to your company’s internal hub, SAML allows you to immediately access GitHub Enterprise repositories, Jira tickets, and Confluence documentation throughout the day without providing your credentials again for each tool. The portal acts as either a SP or an IdP-hosted application launcher, and the downstream tools (Jira, GitHub Enterprise) are additional SPs that trust the same IdP.

SAML supports two initiation patterns, both resulting in SSO.

SP-Initiated Flow (Standard for B2B SaaS)

When a user tries to access the application directly:

1. User attempts to access the application (SP)
2. The application redirects the user to the IdP’s login page
3. User authenticates with the IdP
4. IdP generates a signed SAML assertion
5. IdP redirects the user back to the application with the assertion
6. The application validates the assertion signature and creates a session
7. User accesses your application

IdP-Initiated Flow (Common in Enterprise Environments)

When a user starts from their corporate dashboard:

1. User logs into their corporate portal (IdP)
2. User clicks on the application in their dashboard
3. IdP generates a signed SAML assertion
4. IdP automatically redirects the user to the application (SP) with the assertion
5. The application validates the assertion and creates a session
6. User accesses the application

Both flows verify identity without requiring passwords to be shared between systems. The IdP may require multi-factor authentication (MFA) before issuing the assertion, adding an extra security layer.

IdP-initiated SSO does not include an InResponseTo value from the SP. SPs rely more on assertion timestamps (NotBefore/NotOnOrAfter) and replay protection when validating IdP-initiated assertions.

SAML enables identity federation through three main components:

• IdP: System that authenticates users and stores credentials
• SP: Application relying on the IdP for authentication and granting access
• SAML Assertion: Digitally signed XML document containing verified identity data, passed from IdP to SP

The assertion confirms the user’s identity and the access they are authorized to have, allowing the SP to grant or deny access without handling the user’s credentials directly.

A SAML assertion is a structured XML document with three statement types:

• Authentication statements: Confirm the user is authenticated and record the time the event occurred.
• Attribute statements: Contain user data and claims (email, name, groups, roles). Most deployments convey authorization data (such as roles or groups) through attribute statements. In workforce SAML deployments, attribute statements commonly include authorization-related data such as groups or roles.
• Authorization decision statements: Defined in the SAML spec, but rarely used in today’s SSO implementations.

The assertion includes:

• Issuer: Which IdP created it
• Subject: Who the user is
• Conditions: Validity time window (e.g., NotBefore and NotOnOrAfter) and the intended audience
• Signature: Cryptographic proof of authenticity. The SP must verify that the element being processed is the same element referenced by the signature’s ID to prevent XML signature wrapping attacks.

The assertion may be encrypted, typically the <Assertion> element rather than the entire <Response>, though individual attributes may also be encrypted for sensitive data. The SP must be able to decrypt encrypted elements if necessary.

Developers often confuse SAML with OAuth 2.0 and OIDC. Here’s how they compare:

Aspect	SAML 2.0	OAuth 2.0	OpenID Connect
Primary Use	Enterprise SSO authentication	Delegated authorization	Modern authentication
Format	XML (Complex parsing; risk of XML signature wrapping attacks)	Token format agnostic in the specification, though many implementations use JWT access tokens	JSON-based (JWT ID Token)
Token Type	SAML Assertion	Access Token	ID Token and Access Token
Transport	Authentication requests commonly use HTTP-Redirect; assertions are almost always delivered via HTTP-POST	Typically via HTTP Authorization header (Bearer tokens), though other transports (form_post/query) exist depending on the flow	HTTP Authorization header
Mobile Support	Poor support for native apps (often requires WebView or a broker app)	Excellent	Excellent
Target Audience	Enterprises, governments	Consumer apps, APIs	Consumer apps, modern enterprises
Use Case	Enterprise SSO, workforce authentication	API access delegation, third-party integrations	Modern apps, mobile authentication, consumer SSO

OAuth 2.0 handles authorization (what you can do), not authentication (who you are). OAuth 2.0 alone is not an authentication protocol. Providers often use proprietary methods to layer identity information on top; however, these methods are not standardized. OpenID Connect is the standard for adding authentication to OAuth 2.0.

SAML handles authentication and can include authorization attributes, but it is not an authorization framework. Authorization decisions are made in your application after SAML authentication is complete.

The protocols aren’t mutually exclusive. Many identity platforms support all three, letting you choose based on your users’ needs.

XML Signature Validation

SAML relies on XML signatures for security. Implementing validation correctly is complex:

• Validate the signature algorithm (reject weak algorithms like SHA-1)
• Verify the signing certificate chain
• Check certificate expiration and revocation status
• Ensure the signed element matches the parsed content
• SPs should validate at least one trusted signature (on either the <Response> or the <Assertion>, depending on configuration) and ensure only the expected element is processed
• SPs must ensure the signature covers the correct reference to prevent XML wrapping. Some libraries may not enforce reference coverage. Verify the signature references the correct element ID.

A single mistake in signature validation creates security vulnerabilities. Attackers can exploit XML-signature wrapping to bypass authentication.

Consider using a tested SAML library instead of building one from scratch.

Clock Skew and Timestamp Validation

SAML assertions include (NotBefore) and (NotOnOrAfter) conditions. Clock differences between IdP and SP can cause valid assertions to be rejected.

Best practices:

• Allow a clock skew tolerance of 2–5 minutes
• Implement proper NTP configuration on your servers
• Log timestamp validation failures separately for debugging

Metadata Exchange

SAML typically uses metadata exchange between IdP and SP, although it is not strictly required by the specification:

• IdP metadata: Contains signing certificates, endpoints, and entity ID
• SP metadata: Describes your application’s assertion consumer service (ACS) URLs and requirements

Metadata changes break SSO. When IdPs rotate certificates, you must update the configuration. Some enterprises require manual approval for SP metadata changes, which can delay deployments.

Store IdP metadata in your database, not configuration files. Not all IdPs support dynamic metadata URLs. When available, auto-refresh is the best practice.

Attribute Mapping Inconsistencies

Different IdPs send different attribute names. The application needs flexible attribute mapping to handle these variations. Let customers configure which SAML attributes map to your application’s user fields.

When using role-based access control (RBAC), IdPs can send role information in SAML attributes. The application must map these IdP roles to the internal permission system.

Always Validate the Signature

Every SAML assertion must be cryptographically validated to confirm:

1. The signature exists
2. The signature is valid for the assertion content
3. The signing certificate chains to a trusted root
4. The signed element matches the parsed content. SPs must ensure the signature covers the correct reference to prevent XML wrapping.

Never skip signature validation, even in development. It’s the foundation of SAML security.

Validate All Assertion Conditions

Beyond signatures, validate:

• Issuer: Matches the configured IdP
• Audience: Contains the application’s entity ID
• NotBefore/NotOnOrAfter: Current time falls within the valid window
• Recipient: Matches your assertion consumer service URL (if present)
• InResponseTo: Matches your authentication request ID (for SP-initiated flows)

Prevent Replay Attacks and Signature Wrapping

The SAML specification doesn’t mandate one-time use of assertions, making replay protection the SP’s responsibility.

1. Store the Assertion ID (not the Response ID), used like a nonce to prevent replay, in a cache with TTL matching the assertion validity window
   Best practice: Set the cache TTL to at least the assertion’s NotOnOrAfter window, ideally with a small buffer (a few seconds) to account for network latency
2. Reject any assertion with an ID you’ve seen before
3. Clear expired IDs regularly to manage cache size

As a first defense, the SP should validate NotBefore and NotOnOrAfter timestamps. Caching assertion IDs is secondary.

Use HTTPS Everywhere

SAML assertions should only be transmitted over HTTPS. Even though they are signed, transmitting them over HTTP exposes users to man-in-the-middle attacks.

Configure the assertion consumer service (ACS) URL with HTTPS only. Most IdPs will warn or block HTTP endpoints.

Implement Logout Properly

SAML supports single logout (SLO), enabling users to sign out of all connected applications simultaneously. Implementation is optional but recommended for security-sensitive applications.

SLO can be front-channel (browser redirects) or back-channel (server-to-server). Front-channel SLO is widely supported but fragile. Back-channel logout exists, but it is complex and rarely implemented. Interoperability varies since different IdPs and SPs implement SLO differently, so expect to test multiple providers.

Building a secure SAML implementation from scratch requires deep XML security expertise and is generally recommended only for IdP implementations or highly specialized use cases.

Consider your options:

Identity Platforms

Some identity platforms help handle SAML complexity by providing:

• Pre-built SAML IdP and SP implementations
• Automatic metadata management
• Certificate rotation handling
• Support for multiple IdPs per application
• Detailed audit logs

This approach provides SAML support for enterprise customers while using modern protocols (OIDC, OAuth 2.0) for consumer-facing applications. Some platforms translate between protocols seamlessly.

SAML Libraries

For teams that need more control, mature SAML libraries handle XML parsing, signature validation, and low-level protocol details:

• Node.js: passport-saml, samlify
• Python: python3-saml, pysaml2
• Java: Spring Security SAML, OpenSAML
• .NET: Sustainsys.Saml2, ITfoxtec.Identity.Saml2
• Ruby: ruby-saml
• PHP: SimpleSAMLphp

Even mature SAML libraries do not automatically handle replay attacks or encrypted assertions. Developers must implement caching/nonces and decryption as needed, and ensure the signature reference is verified.

Choose SAML when:

• Customers are enterprises with existing SAML infrastructure
• Building a B2B SaaS requiring enterprise SSO
• Integrating with government systems
• RFP responses require SAML support

Choose OIDC or OAuth 2.0 when:

• Building consumer applications
• Mobile app authentication is needed
• Implementing API authorization
• Simpler JSON-based protocols are preferred
• Starting fresh without legacy requirements

Many applications support multiple protocols. Your IdP choice should support both SAML for enterprise customers and OIDC for all other users. Consider using passwordless authentication methods, like WebAuthn and passkeys, to enhance user experience.

Before launching SAML support, test thoroughly:

Test with Multiple IdPs

Each IdP implements SAML slightly differently. Don’t assume behavior from one IdP applies to others. Attribute names, metadata formats, and certificate handling vary.

Test Edge Cases

• Clock skew (adjust your server time by ±5 minutes)
• Certificate rotation (update IdP certificates and verify no downtime)
• Invalid signatures (tamper with assertions and confirm rejection)
• Expired assertions (use old test assertions)
• Replay attacks (resubmit valid assertions and confirm rejection)

Monitor Validation Failures

Log all SAML validation failures with assertion ID, reason, IdP entity, and timestamp for debugging. These logs are essential for debugging customer issues. SAML failures are often due to configuration issues rather than code bugs.

What problem does SAML solve?

SAML provides SSO by enabling identity federation for enterprise users. Its main benefit is to simplify application security by shifting responsibility for storing and managing user passwords to a dedicated IdP. This reduces the application’s attack surface, cuts down on help desk calls for password resets, and centralizes policy enforcement.

Is SAML Authentication or Authorization?

SAML is primarily an authentication and federation protocol, designed to verify user identity. It is not, by itself, an authorization framework like OAuth 2.0. SAML answers the question: “Who is this user?” by transmitting a signed assertion (an identity statement) from an IdP to a SP. Authorization (determining what the user can do) occurs after SAML authentication completes, typically via user attributes (e.g., role or department) found in the SAML assertion.

How does SAML differ from OAuth 2.0 and OpenID Connect?

SAML is an older, XML-based standard designed for enterprise identity federation and workforce SSO. OAuth 2.0 is an authorization framework issuing access tokens to grant delegated, limited-scope access to APIs. OIDC is an identity layer built on OAuth 2.0 that adds standardized authentication via ID tokens (JWTs), optimized for web, mobile, and API-driven applications. All three enable access, but SAML focuses on enterprise SSO, whereas OAuth and OIDC are better suited for today’s application authentication and API authorization.

Is SAML still used?

Yes. SAML remains a dominant protocol for enterprise SSO, particularly in large organizations and government agencies with existing identity infrastructure. While OIDC has gained traction for applications, SAML’s widespread enterprise adoption means it continues to be actively used and supported.

Is SAML secure? What are the security risks?

SAML is secure when implemented correctly. The protocol uses XML digital signatures and encryption to protect identity data. Risks can stem from improper validation of assertions. SPs must verify XML signatures, validate assertion conditions (including issuer, audience, and timestamps), and implement replay protection.

Auth0 helps developers implement SAML quickly and securely, enabling enterprise SSO without building or maintaining SAML infrastructure from scratch.

Explore our Intro to IAM series on identity and access management.

Learn more

These materials are intended for general informational purposes only. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors and should not rely solely on the information provided herein.