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.
The Operational Load While Both Protocols Coexist
A configuration in which newly adopted services use OIDC while existing services remain integrated over SAML arises widely as a transitional state until migration is complete. What increases during this period is less technical difficulty than verification work: the IdP holds two sets of integration settings for the same users, so adding an account, changing permissions, or disabling access when someone leaves has to be confirmed against both. Troubleshooting procedures diverge as well - on the SAML side, signature verification and certificate expiry are the places to suspect; on the OIDC side, token validation and where the keys are fetched from. Expiry management cannot be unified either, since certificates and client credentials are tracked on separate schedules. The OIDC side is contiguous with OAuth permission management, so the design of the scopes granted needs to be reviewed alongside it. Coexistence itself is hard to avoid, but if the inventory of which service uses which method is not current, permission changes will be missed on one side; setting a deadline for the migration so that the transitional state does not become permanent is therefore the operational key.
Was this article helpful?