SAML (Security Assertion Markup Language) is an open, XML-based standard for exchanging authentication and authorization information between an identity provider and an application. In plain terms, SAML lets a central identity service vouch for you to many separate applications, so you log in once and are trusted everywhere. It is the workhorse behind a great deal of enterprise single sign-on: when an employee signs in to their company portal and then reaches dozens of internal tools without re-entering a password, SAML is very often the standard passing a signed statement — an assertion — that says "this user is authenticated, and here is who they are."
Why It Matters
Large organizations run dozens or hundreds of separate applications. Without a shared standard, each one would maintain its own usernames and passwords, forcing employees to juggle countless logins and forcing IT to create and, crucially, delete accounts in every system whenever someone joins or leaves. That sprawl is both a productivity drain and a serious security risk: forgotten accounts in forgotten systems are a classic way for access to linger long after it should be gone.
SAML centralizes the decision. Identity lives in one trusted place — the identity provider — and every connected application defers to it. When someone leaves, disabling their single central account cuts off access everywhere at once. When they need MFA, it is enforced in one place for all applications. This centralization is why SAML remains deeply embedded in enterprise environments and compliance programs, even as newer standards have emerged for consumer and mobile scenarios. It gives security teams a single, auditable choke point for identity.
A Simple Analogy: A Conference Badge
Think of SAML like the badge you receive when you check in at a large conference. You verify your identity once at registration (the identity provider), and they hand you a badge. From then on, every session room, workshop, and exhibitor booth (the applications) simply glances at your badge and lets you in — they trust the registration desk rather than re-verifying you themselves. The badge is tamper-evident, so nobody can forge one. A SAML assertion is that digital badge: a signed statement the registration desk issues so every other station can trust it at a glance.
How It Works
SAML defines two main roles: the identity provider (IdP), which authenticates users, and the service provider (SP), the application the user wants to reach. A typical "SP-initiated" login flows like this:
1. You visit an application (the service provider)
2. The SP redirects you to the identity provider
3. You authenticate at the IdP (password, MFA, etc.)
4. The IdP creates a signed SAML assertion about you
5. Your browser passes the assertion back to the SP
6. The SP verifies the signature and logs you in
The assertion is an XML document containing statements about the user — who they are and any attributes such as group memberships. Its trustworthiness comes from a digital signature: the identity provider signs the assertion with a private key, and the application verifies it using the provider's public certificate. If a single character were altered in transit, the signature check would fail. This is why correct signature validation is the security heart of SAML; a service provider that fails to verify signatures rigorously can be tricked into accepting forged assertions.
Key Things to Know
A few points clarify where SAML fits:
| Aspect | SAML |
|---|---|
| Data format | XML |
| Core artifact | Signed assertion |
| Identity provider | Authenticates the user, issues assertions |
| Service provider | The application that trusts the assertion |
| Common use | Enterprise and workforce single sign-on |
The most important takeaway is that SAML's security rests entirely on signature verification and correct configuration. It is a mature, capable standard, but its XML processing is intricate, and subtle mistakes in how a service provider parses and validates assertions have historically been a source of serious authentication-bypass flaws.
How Safeguard Helps
SAML is implemented through open-source libraries that parse XML, validate signatures, and process assertions — some of the most security-sensitive code in an application. Vulnerabilities in SAML libraries, particularly around signature validation and XML handling, can lead to full authentication bypass, so keeping those components current is essential. Safeguard's software composition analysis inventories the SAML libraries your project uses and flags any with known vulnerabilities.
Because a raw list of findings is hard to prioritize, Griffin AI highlights the flaws in code your application actually runs and explains the risk in plain language. To understand the neighboring standards — OpenID Connect, single sign-on, and JWTs — the concepts library lays them out clearly. To analyze your own dependencies, create a free account, or work through the fundamentals in Safeguard Academy.
Frequently Asked Questions
What is the difference between SAML and OpenID Connect?
Both enable single sign-on, but they differ in age, format, and typical use. SAML is older, uses XML, and is deeply established in enterprise and workforce scenarios. OpenID Connect is newer, uses JSON and JWTs, and fits mobile and consumer applications well. Many organizations run both: SAML for legacy internal tools and OIDC for modern apps.
What is a SAML assertion?
A SAML assertion is a signed XML document that the identity provider issues to vouch for a user. It states that the user has been authenticated and can carry attributes such as email or group membership. The service provider verifies the assertion's digital signature to confirm it is genuine and unaltered before granting access.
What are the identity provider and service provider?
The identity provider (IdP) is the trusted system that authenticates users and issues assertions — often a central corporate login service. The service provider (SP) is the application the user wants to use, which trusts assertions from the IdP instead of maintaining its own login. The two exchange metadata and certificates up front so they can trust each other.
Why is signature validation so important in SAML?
Because the signature is what proves an assertion genuinely came from the trusted identity provider and was not forged or altered. A service provider that validates signatures incorrectly can be fooled into accepting a fake assertion and logging in an attacker as any user. Flawed signature handling has been a recurring source of serious SAML authentication-bypass vulnerabilities.