What Is SAML?

SAML is the XML-based standard that carries authentication assertions between an identity provider and a service provider. It predates the modern web API era and remains the backbone of enterprise single sign-on, particularly for established business applications.

How the flow works

A user reaches an application, which redirects them to their identity provider. The provider authenticates them and returns a signed assertion stating who they are and, frequently, what groups or attributes they carry. The application validates the signature and establishes a session.

Everything therefore depends on that validation. The assertion arrives through the user's browser — which is under the user's control — so its trustworthiness comes entirely from the signature and the checks performed on it.

Signature validation has a difficult history

SAML implementations have repeatedly been found vulnerable to signature wrapping, where an attacker restructures the XML so that a validly signed element remains present while the assertion the application actually reads is attacker-controlled.

The underlying difficulty is XML canonicalisation: signing and parsing may disagree about which part of the document is authoritative. This is a strong argument for using a mature, maintained library rather than implementing validation, and for keeping that library current.

Beyond the signature, implementations must validate the audience, the expiry, and that the assertion has not been replayed. Each has been missing in real-world vulnerabilities.

Configuration is where most real problems sit

Beyond the protocol-level vulnerabilities, the recurring practical issues are mundane. Certificates used to sign assertions expire, and the resulting outage affects every user of the application at once, usually with an unhelpful error message.

Clock skew between provider and application causes intermittent failures that are difficult to diagnose, because assertions carry validity windows measured in minutes.

And metadata — the configuration describing endpoints and keys — is frequently exchanged once during implementation and never refreshed, so a key rotation at one end breaks the integration at the other.

Session handling after the assertion

SAML authenticates; what happens next is the application’s session, and that session is where the practical security lives. An assertion valid for five minutes that establishes a session valid for two weeks has moved the risk rather than removed it.

Single logout is the other frequently incomplete piece. The specification provides for ending sessions across all connected applications, implementations vary widely, and in practice signing out of the identity provider often leaves application sessions active.

That matters for shared devices particularly, where the next user may inherit a session the previous one believed they had ended.

The thing most worth getting right

Where an integration is being built new rather than maintained, OpenID Connect is generally the better choice for the reasons set out there — simpler validation, automatic key rotation and better fit with modern application architectures.

Where to start

For any application you integrate by SAML, confirm which library performs validation and whether it is current. Hand-rolled validation is where the historical vulnerabilities concentrate.

See SSO and session management. GuardsArm delivers application penetration testing.