How Vexta Tests SAML and OAuth Single Sign-On for Auth Bypass

OAuth and SAML vulnerability testing means checking a single sign-on implementation for the specific ways its trust model can be broken, from general OIDC and SAML misconfiguration to a targeted signature-forgery attack that lets someone authenticate as any user without credentials. Vexta runs OIDC and SAML misconfiguration detectors as part of its standard vulnerability classes, plus a dedicated check for SAML XML Signature Wrapping against the Assertion Consumer Service endpoint.

Why a single sign-on bug is worse than a normal bug

Most vulnerabilities compromise one endpoint, one form, or one user's data. A flaw in single sign-on compromises the trust boundary that every application behind it relies on. If the identity provider's assertion can be forged, every downstream app that trusts that assertion trusts the forgery too, whether it is one internal tool or the entire portfolio of applications wired into the same OAuth or SAML setup.

That is why SSO deserves its own dedicated testing rather than treatment as one more form on the login page. A hunter who finds a working authentication bypass here is not reporting a bug in an app, they are reporting a bug in the thing every app in scope trusts.

What is SAML XML Signature Wrapping?

A SAML assertion is a signed XML document: the identity provider signs a specific block of XML asserting who the user is, and the service provider is supposed to verify that signature and then read the same block it just verified. A signature wrapping attack exploits parsers that do not enforce that link tightly enough. The attacker takes a legitimately signed assertion, copies it into a different position in the XML document, and inserts a forged assertion, claiming to be a different user, in the spot the application actually reads from. If the parser locates the signature by searching the document rather than checking it matches the assertion being processed, the signature still validates, but the identity that gets accepted is the attacker's forged one.

Vexta tests specifically for the XSW1, XSW2 and XSW3 variants of this attack, run against the Assertion Consumer Service (ACS) endpoint, which is the URL a service provider exposes to receive and process incoming SAML responses. Vexta's PoE engine attempts to safely confirm the bypass within scope rather than reporting a bare structural weakness, so a proven result means the forged assertion was actually accepted, not just that the XML shape looked exploitable.

Why this is rated CVSS 9.8

Vexta's own documentation carries this check at CWE-345, insufficient verification of data authenticity, with a CVSS score of 9.8, and describes it plainly: a full SAML auth bypass for any user. That severity reflects what a working exploit actually grants. It is not information disclosure or a way to escalate an existing session. It is a way to become any user on the service provider, including an administrator, without ever having their password, because the service provider's own trust check is the thing that fails.

For a bug bounty program or an internal security team, a proven finding here is the kind of result that gets escalated immediately rather than queued behind lower-severity work, and Vexta's Confidence Score on a proven XSW finding reflects that same severity weighting.

Beyond signature wrapping: OIDC and SAML misconfiguration

Signature wrapping is one specific, well-defined attack. Around it, Vexta runs a broader set of OIDC and SAML misconfiguration detectors, covering the more general ways these two protocols get implemented incorrectly across identity providers and service providers that were never built by the same team and often disagree, subtly, about what the specification actually requires.

That combination matters because SSO vulnerabilities rarely announce themselves as one obvious bug. They tend to be small deviations from spec, a check that got skipped during implementation, that only become a real bypass once someone builds the exact malformed request that exposes the gap.

Authorized testing, not attack tooling

Every SSO check here is framed the same way as the rest of Vexta's proof-of-exploitation approach: it is safe confirmation of a finding inside a scope a program, client, or signed engagement has authorized, not a general-purpose way to attack identity providers. A hunter running this against a target outside an authorized program or without a signed engagement is doing something Vexta was not built to support.

Where a bypass is confirmed within scope, the responsible next step is the same as for any other critical finding: report it through the program's or client's disclosure process rather than acting on the access it grants.

Where SSO testing fits in a scan

SSO and SAML findings go through the same pipeline as every other class Vexta detects: a non-destructive verifier attempts confirmation, results come back proven, refuted, or unproven, and confirmed findings carry a Confidence Score built from severity, detector confidence and proof status. Which specific SSO checks are available depends on the license; see plans on the pricing page for details. For programs where identity is in scope, this is exactly the kind of check worth running as part of a full VAPT engagement rather than skipping because SSO looks like someone else's infrastructure.