SAML (Security Assertion Markup Language) is an open, XML-based standard for exchanging authentication and authorization information between an identity provider and a service provider, long the dominant protocol for enterprise single sign-on. It lets a user authenticate once with an identity provider and access multiple applications that trust that provider’s signed assertions.

SAML predates OIDC and remains deeply embedded in enterprise environments, especially for workforce SSO to SaaS and internal applications. Understanding it matters both for integrating with existing systems and for choosing between it and newer protocols.

How SAML works

SAML defines a flow built on signed XML assertions. When a user tries to access a service (the service provider), they’re redirected to their identity provider. The IdP authenticates the user and returns a digitally signed SAML assertion, an XML document stating who the user is and, optionally, their attributes and permissions. The service provider validates the signature and grants access based on the assertion, without ever handling the user’s credentials. The credential stays with the IdP; the service trusts the signed assertion.

SAML vs. OIDC

SAML and OpenID Connect solve the same core problem (federated authentication and SSO) but differ in age, format, and typical use. SAML is XML-based, mature, and dominant in enterprise/workforce SSO. OIDC is JSON/REST-based, built on OAuth 2.0, and the modern default for web, mobile, and consumer scenarios. OIDC is generally lighter-weight and more mobile-friendly; SAML is entrenched in enterprise B2B and legacy integrations. Many identity platforms support both, since organizations often need to bridge modern and legacy systems.

Where SAML is used

SAML is the workhorse of enterprise SSO: employees signing into dozens of SaaS apps through a corporate identity provider, and B2B federations where organizations grant each other’s users access. Its maturity and broad support in enterprise software mean it isn’t going away, even as new integrations increasingly favor OIDC. For customer-facing (CIAM) scenarios, OIDC is usually preferred, but SAML support remains important for enterprise and B2B use cases.

Considerations

SAML is robust but has quirks: XML parsing and signature validation have historically been sources of implementation vulnerabilities (e.g., XML signature-wrapping attacks), so using well-maintained libraries and validating assertions correctly is essential. Its XML verbosity makes it heavier than OIDC’s JSON tokens, particularly on mobile. Choosing SAML vs. OIDC comes down to the environment (SAML for enterprise/legacy integration, OIDC for modern and consumer identity) and many deployments use both.

Frequently asked questions

What is SAML?

An XML-based standard for exchanging signed authentication and authorization assertions between an identity provider and a service provider, widely used for SSO.

What’s the difference between SAML and OIDC?

SAML is XML-based and dominant in enterprise SSO; OIDC is JSON/OAuth-based and the modern default for web, mobile, and consumer identity.

How does SAML enable SSO?

The identity provider issues a signed assertion the service provider trusts, so the user authenticates once and accesses many apps.

Is SAML still used?

Yes, it’s deeply embedded in enterprise and B2B SSO, though new integrations increasingly favor OIDC.

What is a SAML assertion?

A signed XML document from the identity provider stating who the user is (and optionally their attributes), which the service provider trusts.

Should I choose SAML or OIDC?

SAML for enterprise/legacy and B2B integrations; OIDC for modern web, mobile, and consumer identity, many deployments support both.

Related: OpenID Connect (OIDC) · Single Sign-On (SSO) · Identity Federation · Identity Provider (IdP) · OAuth 2.0