SAML
OASIS-standardized federated authentication protocol
SAML, the Security Assertion Markup Language, is an XML-based authentication standard, maintained by OASIS, that lets an identity provider assert a user's authenticated identity to a separate service provider, enabling single sign-on…
Definition
SAML, the Security Assertion Markup Language, is an XML-based authentication standard, maintained by OASIS, that lets an identity provider assert a user's authenticated identity to a separate service provider, enabling single sign-on across otherwise unrelated applications. A user logs in once with the identity provider, which then issues a signed assertion that the service provider trusts, letting the user access multiple applications without re-entering credentials at each one.
Overview
Large organizations historically managed separate logins for every internal and third-party application an employee used, which created both a poor user experience and a security liability, since password reuse and account sprawl made credential compromise more likely and offboarding an employee meant disabling access in many disconnected systems. SAML was developed in the early 2000s to let a single identity provider handle authentication centrally while any number of separate service providers trust that identity provider's assertions instead of managing their own credential stores. Mechanically, a SAML exchange typically begins when a user tries to access a service provider's application without an active session. The service provider redirects the user's browser to the identity provider, which authenticates the user, commonly through a username and password or multi-factor authentication, and then constructs a SAML assertion, an XML document containing statements about the user's identity and often additional attributes like group membership or role. This assertion is digitally signed using XML signature standards and returned to the service provider through the user's browser, typically via an HTTP POST binding, where the service provider verifies the signature against the identity provider's known public key before establishing a session for the user. SAML differs from OpenID Connect primarily in its data format and era of design: SAML relies on XML and predates the mobile and JavaScript-heavy web application patterns that OpenID Connect was later designed to fit more naturally, since parsing and validating XML signatures is more involved in browser-based JavaScript than working with OpenID Connect's JSON Web Tokens. SAML remains deeply entrenched in enterprise software, however, particularly in large organizations with established identity infrastructure and vendor software that was built before OpenID Connect existed. In practice, SAML underlies single sign-on integrations between corporate identity providers like Okta, Microsoft Entra ID, or Auth0 and business applications such as Salesforce, Slack, and internal enterprise portals. IT administrators configure a trust relationship once between the identity provider and each service provider, after which employees authenticate a single time and gain access to every connected application without additional logins. The protocol's XML-based design is verbose and more complex to implement correctly than newer alternatives, and its security depends heavily on validating the signed assertion properly; improperly implemented SAML consumers have historically been vulnerable to XML signature wrapping attacks, where an attacker manipulates the XML structure to make a forged assertion appear validly signed. Because of this complexity, most organizations rely on established libraries or managed identity platforms rather than implementing SAML parsing and validation from scratch.
Specification
- Uses XML-based signed assertions to convey authenticated identity
- Enables single sign-on across otherwise unrelated service providers
- Requires a configured trust relationship between identity and service providers
- Supports carrying additional user attributes like role or group membership
- Relies on digital signatures to prevent assertion tampering
- Commonly used via HTTP POST or redirect bindings through the browser
- Predates and differs structurally from JSON-based OpenID Connect
- Deeply integrated into established enterprise software ecosystems