SAML, the Security Assertion Markup Language, is an open XML-based standard from OASIS for exchanging authentication and authorization data between an identity provider and a service provider. In cybersecurity identity and access management it is the long-established foundation of enterprise single sign-on, letting a user who has signed in once at a corporate identity provider reach many web applications without separate passwords.
The current version, SAML 2.0, was ratified in 2005 and remains widely deployed for workforce access to software-as-a-service applications. Its core idea is the digitally signed assertion: an XML document in which the identity provider vouches for who the user is, how they authenticated and which attributes they hold.
How SAML single sign-on works
SAML defines three roles: the principal (the user), the identity provider (IdP) that authenticates the user, and the service provider (SP), the application the user wants to reach. The two providers never exchange passwords; they rely on a pre-established trust based on exchanged metadata and signing certificates.
The most common pattern is SP-initiated web browser SSO, in which the browser carries all messages between the two providers. The steps are shown below.
| Step | What happens | Binding typically used |
|---|---|---|
| 1. Access request | User opens the application without a session | Plain HTTPS request |
| 2. AuthnRequest | SP redirects the browser to the IdP with a request | HTTP-Redirect |
| 3. Authentication | IdP verifies the user, often with MFA | IdP login page |
| 4. Response | IdP returns a signed Response with an assertion | HTTP-POST via auto-submitted form |
| 5. Validation | SP checks signature, audience, time and recipient | Inside the SP |
| 6. Session | SP creates its own session for the user | Application cookie |
In IdP-initiated SSO, the user starts at an identity provider portal and clicks an application tile, so step 2 is skipped. It is convenient but weaker, because the SP receives an unsolicited response that it cannot match to a request it sent.
Assertions, bindings and metadata
SAML 2.0 is organized into assertions, protocols, bindings and profiles. Assertions carry the claims, protocols define request and response messages, bindings map those messages onto transports such as HTTP, and profiles combine everything into use cases like web browser SSO or single logout.
| Element | Purpose | What the SP must check |
|---|---|---|
| Issuer | Identifies the IdP that created the assertion | Matches a trusted IdP |
| Signature | XML signature over the assertion or response | Valid with the IdP certificate |
| Subject and NameID | Identifies the user | Expected format, often email or persistent ID |
| Conditions | NotBefore, NotOnOrAfter, AudienceRestriction | Time window and own entity ID |
| AuthnStatement | When and how the user authenticated | Acceptable authentication context |
| AttributeStatement | Attributes such as groups or department | Mapped to application roles |
Metadata is an XML document each party publishes with its entity ID, endpoints and certificates. Exchanging metadata sets up the trust, and certificate rollover must be planned, because an expired IdP signing certificate breaks logins for every connected application at once. Assertion lifetimes are usually short, often a few minutes, to limit replay.
SAML compared with OpenID Connect and OAuth 2.0
SAML, OpenID Connect and OAuth 2.0 are often mentioned together, yet they solve different problems. SAML and OpenID Connect both provide federated authentication for SSO, while OAuth 2.0 is an authorization framework for delegated API access and does not by itself prove who the user is.
| Aspect | SAML 2.0 | OpenID Connect | OAuth 2.0 |
|---|---|---|---|
| Primary purpose | Federated authentication | Federated authentication | Delegated authorization |
| Token format | Signed XML assertion | Signed JSON Web Token | Access token, format not mandated |
| Typical clients | Browser-based enterprise apps | Web, mobile and single-page apps | APIs and services |
| Transport | Browser redirects and POST | Redirects plus JSON endpoints | Redirects plus JSON endpoints |
| Mobile friendliness | Limited | Good | Good |
New consumer and mobile projects usually choose OpenID Connect, while SAML remains the default language of enterprise SaaS integrations. Most identity providers support both, so an organization can use each where it fits.
Security risks and implementation pitfalls
SAML’s security rests almost entirely on correct signature validation, and XML makes that harder than it looks. Several well-documented vulnerability classes come from service providers that parse or verify assertions incorrectly.
| Weakness | Effect | Defense |
|---|---|---|
| XML signature wrapping | Attacker injects unsigned content the SP trusts | Use only the signed element after validation |
| Missing signature check | Forged assertions accepted | Require signed assertions or responses |
| Comment injection in NameID | Identity truncated to another user | Use patched, canonicalizing libraries |
| No audience or recipient check | Assertion for one SP reused at another | Validate AudienceRestriction and Destination |
| Replay | Captured response used again | Enforce short validity and track assertion IDs |
| Weak algorithms | Forgeable or breakable signatures | Require RSA-SHA256 or stronger |
The strongest practical advice is to never write a custom SAML parser: use a mature, maintained library, keep it updated and test it with known attack payloads. Encrypting assertions protects attributes in transit through the browser but does not replace signature validation.
Deploying SAML in an organization
- Centralize authentication at one identity provider and enforce MFA or passkeys there, so every SAML application inherits it.
- Map groups to roles through attributes rather than managing permissions separately in each application.
- Pair SSO with provisioning through SCIM, because SAML creates sessions but does not remove accounts when people leave.
- Monitor certificate expiry and publish new signing certificates in metadata well before rollover.
- Disable local passwords in applications once SSO works, or attackers can bypass the identity provider.
Single logout, the SAML profile that ends sessions at every service provider at once, is unevenly supported across applications and often unreliable in practice. Organizations therefore keep application session lifetimes short and rely on the identity provider to refuse new assertions once an account is disabled, instead of assuming that one logout click ends every session.
A non-technical view
Picture a large office building where a front desk checks your badge once in the morning. After that, each department lets you in because it trusts the front desk, not because you show a separate pass at every door. SAML is the agreed format for that trusted note from the front desk.
Your company’s sign-in service checks who you are, then hands each application a sealed, signed note saying so. The application checks the seal and lets you in, so you remember one login instead of dozens.
A concrete example
A university with 6,000 staff uses about 40 cloud applications, each with its own password, and the help desk spends much of its time on password resets. The IT team connects the applications to the university’s identity provider through SAML, exchanging metadata with each vendor and mapping department groups to application roles.
After the rollout, staff sign in once with a password and a phone-based second factor, and password reset tickets fall noticeably. When an employee leaves, disabling a single account at the identity provider ends access to every connected application, and an audit confirms that no application still accepts local passwords.