SAML - Security Assertion Markup Language
About 2 min read
SAML (Security Assertion Markup Language) is an open standard for securely exchanging XML-based authentication and authorization information across different domains. SAML 2.0 was established by OASIS in 2005 and has served for over 20 years as the de facto standard for single sign-on (SSO) in enterprise environments. Even as OpenID Connect (OIDC) rises to prominence for modern applications, demand for SAML remains strong because of its compatibility with existing enterprise systems.
The SAML 2.0 Authentication Flow
The SAML authentication flow has two patterns: SP-initiated (originating from the SP) and IdP-initiated (originating from the IdP). In practice, SP-initiated is used far more often.
The Structure of a SAML Assertion
A SAML assertion is an XML document through which the IdP conveys the result of user authentication to the SP. It is composed mainly of three elements.
Describes when and by what method the user was authenticated. Includes the authentication time and the authentication method (password, MFA, etc.).
Stores the user's attribute information (email address, department, role, etc.). The SP uses this information to perform access control.
Describes whether access to a specific resource is permitted. It is rarely used in practice, and authorization is often decided on the SP side.
Comparison with OIDC
Both SAML and OIDC are protocols that enable federated authentication, but they differ greatly in design philosophy and technical foundation. For new projects, OIDC is often the first choice, but in existing enterprise environments there are quite a few cases where SAML is mandatory.
| Aspect | SAML 2.0 | OIDC |
|---|---|---|
| Data format | XML | JSON / JWT |
| Year established | 2005 | 2014 |
| Main use case | Enterprise SSO | Web and mobile apps |
| Implementation complexity | High (XML signatures, certificate management) | Low (JSON-based) |
| Mobile support | Difficult (assumes browser redirects) | Native support |
| Token size | Large (several KB) | Small (a few hundred bytes) |
Why SAML Persists in Legacy Systems
Even though OIDC is more modern and easier to implement, there are several reasons why SAML remains widely used in enterprise environments. First, major SaaS products such as Salesforce, Workday, and ServiceNow have supported SAML for years, and migrating existing integration settings to OIDC carries a high cost. Second, in-house Active Directory Federation Services (AD FS) is built on the assumption of SAML, making infrastructure renewal difficult. Third, audit and compliance requirements sometimes call for a "proven protocol." The article on corporate password policy also touches on choosing an SSO protocol.
A SAML-specific Vulnerability - XML Signature Wrapping Attacks
Because SAML is XML-based, it carries a unique vulnerability called XML Signature Wrapping (XSW). In this attack, a legitimate signed assertion is moved within the XML document, and a forged assertion created by the attacker is inserted at a position outside the scope of signature verification. If the SP's XML parser looks at different nodes for signature verification and for value reference, the attacker may be able to log in as any user. The key countermeasure is to implement the verification logic for digital signatures strictly and to prevent XPath injection.
- During signature verification, validate only specific elements rather than the entire XML document
- Keep the SAML library at the latest version and apply patches for known XSW vulnerabilities
- Strictly validate the schema of the assertions received on the SP side
- Use encrypted assertions (EncryptedAssertion) whenever possible
Common Misconceptions
There is a misconception that "SAML is old, so it is not secure," but the security design of the protocol itself is robust. Problems arise from implementation flaws (lax signature verification, missed certificate rotation, etc.), not from the SAML specification. Check the implementation checkpoints for introducing SSO in the startup security checklist.web security books on Amazon are also a useful reference.
Real-World Use Cases
"At our company, we use Microsoft Entra ID as the IdP and integrate with more than 30 SaaS products via SAML. For newly introduced SaaS, we prioritize OIDC support, but our integrations with existing Salesforce and ServiceNow continue to run on SAML. The coexistence of both protocols is complex, including OAuth permission management, but a phased migration is the realistic choice."
Was this article helpful?