What Is SAML 2.0: SSO Flow, OAuth/OIDC and Vulnerabilities

SAML is the XML standard that lets a user authenticate once at the corporate IdP and access multiple applications without typing credentials again. The acronym stands for Security Assertion Markup Language. SAML 2.0 has been the current version since 2005 and, despite its age and the rise of OAuth 2.0 and OpenID Connect, it remains the basis of Single Sign-On in most corporate environments: ADFS, Azure AD/Entra ID, Okta, Ping, Auth0, OneLogin and Salesforce all speak SAML.

This guide explains what SAML specifically is, how the SSO flow with IdP and SP works, the technical components (assertions, bindings, profiles, metadata), useful comparison with OAuth 2.0, OIDC and JWT, the classic vulnerabilities appearing in pentesting (XML Signature Wrapping, assertion replay, NameID manipulation, Issuer substitution), configuration best practices and how it fits compliance like NIS2, DORA, ISO 27001 and PCI DSS.

What SAML is

SAML is an OASIS XML-based standard defining how authentication and authorisation data get exchanged between an identity provider and one or several client applications. It solves the classic problem of "having to log in 30 times a day": the user authenticates once against the corporate IdP and, from then on, applications that accept SAML assertions let them in.

The protocol actors:

• Identity Provider (IdP). Who authenticates the user and issues signed assertions. Examples: Microsoft Entra ID, Active Directory Federation Services (ADFS), Okta, Ping Identity, Auth0, Keycloak.
• Service Provider (SP). The application that trusts the IdP to authenticate its users. Examples: Salesforce, ServiceNow, Workday, Slack, GitHub Enterprise, SaaS applications and almost any internal corporate application supporting SSO.
• SAML Assertion. Signed XML document the IdP issues and the SP validates. Contains the user's identity, attributes (role, department, email), validity conditions and digital signature.
• User Agent. The user's browser, which acts as intermediary in the SSO flow.

How the SSO flow with SAML works

The most used flow in enterprise (SP-Initiated, HTTP POST Binding) always follows the same steps:

1. The user opens the SaaS application (https://app.example.com). The SP detects there's no session.
2. The SP builds a SAML AuthnRequest, signs or encrypts it per policy, base64-encodes it and redirects the user's browser to the corporate IdP (https://idp.company.com/sso).
3. The IdP validates the AuthnRequest, checks the user's session and, if there isn't one, asks for credentials (typically username and password plus MFA).
4. After authentication, the IdP builds a SAML assertion with the user's identity and attributes, signs it with its private key and delivers it to the browser in an HTTP response containing an auto-submit form to the SP.
5. The browser POSTs to the SP's Assertion Consumer Service (ACS) endpoint with the signed assertion.
6. The SP verifies the signature using the IdP's public certificate (which it must have configured), validates conditions (timestamp, audience), extracts the attributes and creates a local session.
7. The user is inside the application without having typed anything into it.

Variants exist (IdP-Initiated, Redirect Binding, Artifact Binding) but the essential mechanics are the same: the IdP signs, the SP verifies.

Key components of the standard

Four elements cover the bulk of the technical work.

Assertions. The core. Signed XML documents asserting something about the subject. Three types:

• Authentication Assertion: the subject authenticated at this moment using this method.
• Attribute Assertion: the subject has these attributes (email, role, group).
• Authorization Decision Assertion: the subject is authorised to do X (rarely used in classic SSO).

Bindings. How the assertion gets transported. The most-used:

• HTTP Redirect: assertion in query string, compressed. For short AuthnRequests.
• HTTP POST: assertion in auto-submit form. The most common for full assertions.
• HTTP Artifact: the SP receives an identifier and queries the IdP via SOAP to retrieve the assertion. More secure but less compatible.

Profiles. Combinations of bindings and assertions for specific cases. The most used: Web Browser SSO Profile.

Metadata. Public XML each party exposes with its configuration (URLs, certificates, required attributes). The SP and IdP exchange metadata when setting up and refresh periodically.

SAML vs OAuth 2.0, OIDC and JWT

Confusion between these protocols is common. The practical differences:

• SAML is designed for SSO authentication in enterprise applications, based on XML, signed assertions. Dominant in B2B and corporate tools.
• OAuth 2.0 is designed for delegated authorisation: an application accesses resources of another on behalf of the user without the user sharing credentials. JSON tokens, not XML.
• OpenID Connect (OIDC) builds on top of OAuth 2.0 and adds authentication. Dominant in mobile apps, modern SPAs and APIs.
• JWT is the token format used by OAuth 2.0 and OIDC, also by modern web applications for stateless sessions. Independent from the protocol.

When does an organisation pick each:

• Legacy corporate SaaS applications: SAML for compatibility. Still the most widespread format in B2B RFPs.
• Mobile applications, SPAs or public APIs: OIDC for simplicity and native support in modern SDKs.
• Internal applications the team fully controls: OIDC almost always, unless there's already a profitable SAML IdP.
• Large federations (universities, government, health): SAML maintains strong presence by institutional inertia.

In 2026 many companies operate hybrid IdPs (Entra ID, Okta, Auth0) speaking both protocols simultaneously and let each SP choose. The trend is OIDC for everything new and SAML for legacy.

Common vulnerabilities in pentesting

SAML is one of the most profitable targets in a professional web audit. Classic vulnerabilities keep appearing in production. In audits of production SPs, XSW and the lack of Issuer validation are the two findings that repeat most in old SPs or those built with unupdated libraries.

XML Signature Wrapping (XSW)

The SAML assertion gets cryptographically signed, but the signature applies to a specific section of the XML. If the SP validates the signature over one section and then processes information from a different section, the attacker can pack two assertions in the same document: the signed one (with legitimate data) and another injected one (with attacker data). Well-crafted, the SP validates the signed and processes the injected.

There are eight documented variants (XSW1 to XSW8). Auditing them by hand is costly; tools like SAML Raider (Burp Suite extension) automate payload generation.

XML External Entities (XXE)

If the SP's XML parser processes external entities, the attacker includes in the assertion references to local files (/etc/passwd, file:///c:/windows/win.ini) or internal URLs. The SP resolves them and returns the content or triggers an SSRF connection to the backend.

Defence: configure the XML parser to disable external entity resolution. Modern languages and libraries usually have it disabled by default, but legacy code in Java, Python or .NET stays vulnerable.

NameID or attribute manipulation

If the SP trusts the NameID or attributes like Email to identify the user without proper validation, an attacker with control over any of those fields can impersonate. Typical cases:

• IdP configured to send Email and SP that creates a new account or associates to an existing account without double verification.
• Applications with transient NameID where it's assumed persistent.
• Custom attribute mapping without format validation.

Assertion Replay

If the SP doesn't mark assertions as used after consuming them, an attacker who intercepts a legitimate assertion can reuse it within the validity window (NotOnOrAfter typically 5 minutes). Defence: cache of already-consumed assertion identifiers, strict timestamp and Audience validation.

Signature bypass with random <ds:Signature>

Some SPs accept assertions with <Signature> element present but not actually validated, or accept <Signature> elements inserted in unexpected positions in the XML. Specific variant of XSW deserving dedicated audit.

Issuer substitution

The SP must validate that the assertion's Issuer matches the trusted IdP. If it doesn't, an attacker with their own IdP can issue assertions and send them to the victim SP. This flaw appeared in old versions of several libraries, including public cases in GitHub Enterprise (2017) and other platforms.

Notable historical vulnerabilities

• CVE-2017-11427 and family: SAML authentication bypass in multiple libraries (OneLogin Ruby SAML, Clever-Tools), mishandled XML comments that made the parser see one NameID and the signature see another.
• CVE-2020-14322 (mod_auth_mellon): bypass via URI parsing.
• CVE-2024-39689 (xml-crypto): modern XSW variant.

Every release of an XML parser has potential to introduce new variants. Keeping the library updated is necessary but not sufficient; reviewing validation code by hand stays part of any serious audit.

Configuration best practices

What serious teams apply when deploying or auditing SAML in production.

• Sign both assertions and SAML responses (not just assertions). Some configurations sign one but not the other and leave open surface.
• Force TLS 1.2+ on HTTP bindings. Although the assertion is signed, TLS protects attribute confidentiality.
• Validate Issuer, Audience, NotOnOrAfter, NotBefore, Recipient, Destination in every response. Anything omitted is a vector.
• Cache of already-consumed assertion IDs throughout the validity window (better: well beyond).
• IdP signing certificate rotation with a reasonable period. Keep the SP updated via fresh metadata.
• Mandatory MFA at the IdP. SAML SSO's promise breaks if the original login is just a password.
• Centralised SSO event logs. Detection of anomalous logins, assertions with unexpected destination, recurring errors.
• Periodic review of applications trusting the IdP. Remove forgotten SPs from the trust relationships list.
• Validate XML parser against XXE, XSW and variants with automated tests in CI/CD.

Operational detail in a professional web audit.

Compliance fit

Misconfigured or outdated SAML materialises risks covered by current frameworks:

• NIS2 (article 21). Access control, authentication, identity management. A SAML vulnerability allowing impersonation is defensible non-compliance in an audit.
• DORA (article 9). ICT resilience in financial services. SAML federations between entities require formal control.
• ISO 27001:2022 (controls 5.16, 8.5, 8.26). Identity management, secure authentication, application security requirements.
• ENS Royal Decree 311/2022. Measures op.acc (access control) and op.exp.10 (information in transit protection).
• PCI DSS v4.0 (req. 7, 8). Access control and authentication for environments processing card data.
• GDPR. SAML vulnerabilities leaking personal data in assertions or allowing improper access are notifiable breaches.

Frequently asked questions

What's the difference between SAML and SSO?

SSO is the concept: authenticate once to access several applications. SAML is a protocol implementing SSO. Other protocols also implement it (OIDC, Kerberos in Active Directory, CAS). In enterprise the word "SSO" usually refers to SAML by inertia, but technically they're different things.

Is SAML obsolete versus OIDC?

No. It's more mature and more implemented. OIDC is more modern, simpler and better for mobile and SPAs, but SAML still dominates in corporate SaaS and academic/government federations. Most companies run both in parallel.

Why does SAML use XML when everything new uses JSON?

Because it was designed in 2003-2005 when XML was the standard option for signed data. Digital signature over XML (XML Signature) is well specified and widely implemented, although verbose. OIDC chose JWT (JSON) for simplicity, which also introduced other problems (none algorithm, type confusion).

Is the IdP-Initiated flow safe?

It's weaker than SP-Initiated. Without the prior signed AuthnRequest, the SP can't verify that the flow started with the legitimate user. Allows unsolicited response replay attacks. The modern recommendation is to prefer SP-Initiated and disable IdP-Initiated when not strictly necessary.

How do I audit an existing SAML integration?

Three basic steps: 1) SP configuration review (what it validates, what it ignores, which bindings it accepts); 2) automated tests with tools like SAML Raider, samlpy or OWASP test suites; 3) manual review of the XML parser and the logic mapping assertion to session. It's specialised work that in mid-sized enterprise usually requires an external auditor.

What happens if the IdP certificate expires?

All SAML authentication stops working immediately. Certificate rotation is one of the most common operational incident points. Best practice: dual active certificate period, expiration monitoring, metadata update automation on SPs.

Does SAML protect against phishing attacks?

Only partially. If the attacker impersonates the IdP page and the user types credentials, SAML doesn't help. Real defence against phishing in SSO flows is strong phishing-resistant MFA (FIDO2/WebAuthn) on the IdP login, not the protocol itself.

Related resources

• What is JWT and token security: the token format used by OAuth 2.0/OIDC, modern alternative to SAML.
• What is PKI: certificate infrastructure underlying SAML signature and TLS.
• Web application pentesting: the context where SAML vulnerabilities systematically appear.
• API pentesting REST and GraphQL: where the equivalent pattern with OAuth/OIDC gets audited.

SAML audit at Secra

At Secra we review the SAML implementation as a standard part of any deep web audit: validation against the 8 XSW vectors, verification of Issuer/Audience/timestamp validation, XML parser test against XXE, review of NameID-to-session mapping, replay resilience evaluation and IdP configuration review (response signing, mandatory MFA, logs). If your organisation has its own IdP (ADFS, Keycloak) or federation with several corporate SPs and the SSO flow has never been audited, get in touch via contact or check our web and mobile audit service.