SAML Authentication Explained: How Enterprise SSO Works

Introduction

When you click “Sign in with Google” on a corporate app and find yourself already authenticated without entering credentials, you have experienced the product of a SAML-powered identity federation at scale. A single employee at a Fortune 500 company might access 40 to 80 different software applications — email, CRM, HR platform, project management tools — each of which must verify who they are. Without a federated identity standard, every application would need its own authentication system, its own password database, and its own login page.

SAML (Security Assertion Markup Language) solved this problem for enterprise IT in 2005 and remains the dominant standard for enterprise single sign-on (SSO). Over 80% of enterprise organizations use SAML for identity federation with SaaS applications. Major enterprise identity providers — Microsoft Entra ID, Okta, Google Workspace, and PingFederate — all speak SAML natively.

Understanding how SAML works is essential for anyone involved in enterprise security architecture, application development, or compliance — because SAML’s security properties are only as strong as its implementation.

What Is SAML?

SAML (Security Assertion Markup Language) is an open standard developed by OASIS that defines how identity and authentication data is exchanged between parties — specifically between an Identity Provider (IdP) and a Service Provider (SP) — using digitally signed XML documents called assertions.

The core function of SAML in practice is federated Single Sign-On (SSO): allowing a user who has been authenticated once at a central identity system to access multiple, independent applications without re-authenticating at each one.

Three key roles define every SAML interaction:

• Principal: The end user attempting to access a resource.
• Identity Provider (IdP): The authoritative system that manages the user’s identity and authenticates them. The IdP issues SAML assertions vouching for the user’s identity.
• Service Provider (SP): The application or service the user wants to access (e.g., Salesforce, ServiceNow). The SP trusts assertions from the IdP and grants access accordingly.

How SAML Authentication Works

The most common SAML flow is the SP-initiated Web Browser SSO flow, which follows these steps in sequence.

1. Access request: The user attempts to access a protected resource on the SP (e.g., https://app.salesforce.com/customer-data).
2. SP redirects to IdP: The SP detects that the user is not authenticated. It generates a SAML AuthnRequest — an XML-formatted authentication request — and redirects the browser to the user’s IdP, embedding the AuthnRequest in the URL (via HTTP Redirect binding) or a hidden form field (via HTTP POST binding).
3. IdP authenticates the user: The IdP presents a login page if the user doesn’t have an active session. The user authenticates using their corporate credentials (password, MFA, smart card, etc.).
4. IdP generates and signs the assertion: After successful authentication, the IdP creates a SAML Response containing one or more Assertions. The assertion declares: who the user is (NameID), which IdP authenticated them (Issuer), when the assertion is valid (Conditions), and what attributes they have (email, role, department). The IdP signs the response or assertion XML using its private key.
5. Assertion posted to SP: The IdP redirects the user’s browser to the SP’s Assertion Consumer Service (ACS) URL, submitting the signed SAML Response via HTTP POST.
6. SP validates and grants access: The SP validates the signature using the IdP’s public key certificate, verifies the audience and expiry conditions, creates a local session, and grants the user access to the requested resource.

VIDEO · READY 16:9

PLAY

What is SAML? A Comprehensive Guide with Examples

SAML vs OAuth 2.0 and OIDC

These three standards are frequently confused, yet they solve different problems.

SAML excels in enterprise environments with existing IdPs and on-premises applications. For new cloud-native applications, OIDC (built on OAuth 2.0) is generally preferred for its lighter JSON-based tokens and better mobile support. Most major enterprise IdPs support both protocols simultaneously, allowing organizations to use SAML for legacy SaaS apps and OIDC for new applications.

Real-World Use Cases

Enterprise SaaS Access Management: A company with 5,000 employees uses Microsoft Entra ID as their corporate IdP. They provision 65 SaaS applications — Salesforce, Workday, ServiceNow, Slack, GitHub Enterprise — all integrated via SAML SSO. When an employee joins, HR provision their account in Entra ID with the appropriate role attributes. SAML automatically propagates this identity to all 65 applications. When the employee leaves, revoking their Entra ID account instantly terminates access to all 65 applications — without requiring 65 separate deprovisioning actions.

Government Identity Federation: The U.S. federal government’s login.gov service uses SAML to federate identity across dozens of federal agency applications. A veteran using va.gov can seamlessly transition between services at multiple agencies using a single federally-issued identity — no separate credentials per agency. The signed SAML assertion carries the verified identity level (IAL2, which involves identity proofing) across the federation.

Cross-Organization Federation: Two healthcare systems merge and need to give physicians at Hospital A access to applications at Hospital B during a transition period. Rather than creating duplicate accounts in Hospital B’s directory, the two IdPs are federated via SAML. Physicians at Hospital A present their Hospital A SAML assertion to Hospital B’s applications, which are configured to trust assertions from Hospital A’s IdP — enabling cross-organizational access without credential duplication.

Common Mistakes to Avoid

The most exploited SAML security vulnerability is signature wrapping (XSW) attacks. In an XSW attack, an attacker intercepts a legitimate SAML response, duplicates the signed elements, and injects malicious content in a position that some SAML parsers process first — before validating the signature. Poorly implemented SAML libraries that do not correctly enforce which XML node is signed are vulnerable. Always use a well-maintained, actively-audited SAML library rather than writing XML parsing from scratch, and verify your library against the OWASP SAML Security Cheat Sheet.

A second common mistake is accepting unsigned assertions. The SAML specification allows either the Response wrapper or the individual Assertion to be signed. A misconfigured SP that only validates the signature on the Response envelope — and not on the Assertion itself — may accept a response where the assertion content has been modified. Require signature on the Assertion element, not just the Response.

Organizations also fail to enforce audience restriction. A SAML assertion includes an <AudienceRestriction> element specifying which SP the assertion is issued for. If an SP does not validate that its own entity ID is the intended audience, an attacker who obtains a valid assertion for one SP can potentially replay it against another SP trusting the same IdP.

Getting Started

Setting up SAML SSO for an enterprise application requires configuration on both the IdP and SP sides.

1. Choose your IdP: If you are deploying enterprise SAML, your corporate IdP (Okta, Entra ID, Google Workspace, PingFederate) is already chosen. For a new application, identify which IdP your users’ organizations use.
2. Exchange metadata: SAML relies on XML metadata files that describe each party’s entity ID, signing certificates, ACS URLs, and supported bindings. Export your IdP’s metadata and import it into your SP, and vice versa. This establishes mutual trust.
3. Configure attribute mapping: Decide which user attributes the IdP assertion should contain (email, first name, last name, role) and how the SP maps these to user accounts. Use consistent attribute names (preferably from SAML attribute name schemas like urn:oid: or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress).
4. Test with SAML tracer tools: Browser extensions like SAML Tracer (Firefox) or Chrome’s SAML DevTools allow you to inspect the full SAML assertion flow, verifying that signatures, audience restrictions, and attribute values are correct.
5. Pair with Just-In-Time provisioning or SCIM: SAML handles authentication but not provisioning. Pair your SAML integration with SCIM (System for Cross-domain Identity Management) to automate user account creation and deprovisioning in SaaS applications based on IdP directory changes.

Understanding SAML is foundational to enterprise identity management. Pair SAML SSO with strong access control models like RBAC or ABAC so that fine-grained permissions are enforced after authentication. To understand the modern counterpart that works alongside SAML in cloud-native environments, see our guide on OAuth 2.0 and OpenID Connect Explained.