The SSO pitch is compelling and accurate: instead of managing credentials across dozens of applications, users authenticate once with a trusted identity provider, and that authentication propagates to every connected application. One login. One credential to secure. One place to enforce MFA, one place to revoke access, one place to manage the identity lifecycle.
The security benefits are real. Organizations with well-implemented SSO have fewer credential-based breaches, better MFA adoption, and more reliable offboarding. The problem is not the concept. The problem is the gap between what SSO promises and what most SSO implementations actually deliver.
SSO implementations accumulate misconfigurations the way any complex integration does through library defaults that were never revisited, validation steps that were skipped when the integration was first built under time pressure, and security properties that are assumed rather than verified. The difference between SSO misconfigurations and most other authentication bugs is that SSO is positioned as the security layer it is what the organization points to when asked about authentication. A misconfigured SSO implementation is more dangerous than no SSO at all precisely because it creates confidence that is not warranted.
Seven misconfigurations appear more consistently than any others across real SSO assessments. They appear in enterprise SAML integrations, in OIDC implementations at SaaS companies, in identity provider configurations that were set up years ago and never reviewed. Some of them look like security — they have the right libraries, the right protocol, the right documentation in the architecture diagram. The issue is in the details that the architecture diagram never shows.
Misconfiguration 1: SAML Signature Not Validated on Every Assertion
SAML Security Assertion Markup Language passes identity information from the identity provider to the service provider in a signed XML document called an assertion. The signature is what makes the assertion trustworthy: only the identity provider's private key can produce a valid signature, so a service provider that verifies the signature can trust that the assertion came from the IdP and has not been tampered with.
The misconfiguration: service providers that accept unsigned assertions, that verify the signature on the SAML response but not on the individual assertion within it, or that accept assertions signed with a key that is not the configured IdP's key.
SAML responses and SAML assertions are distinct elements in the XML document, and both can carry signatures independently. Some SAML libraries, when configured incorrectly or when using permissive defaults, verify that a signature is present somewhere in the SAML document without verifying that it covers the assertion containing the identity claims. An attacker who can intercept or inject into the SAML flow can produce a response with a valid signature on the outer envelope and manipulated claims in the inner assertion.
The practical consequence: an attacker who can modify the assertion content changing the NameID to a privileged account's identifier, or changing the attribute values that determine role assignment can authenticate as any user in the system if the service provider accepts assertions without validating the signature covering the assertion specifically.
How to test: Capture a legitimate SAML assertion, modify the NameID to an administrative account, and submit the modified assertion. If the service provider authenticates you as the modified identity, signature validation on the assertion is absent or insufficient.
Misconfiguration 2: XML Signature Wrapping Attacks
XML Signature Wrapping XSW is a class of attack against SAML implementations that exploits the relationship between where a signature is and what it covers. A valid SAML assertion contains a signature that covers the assertion's content. An XSW attack constructs a SAML response that moves the valid signature to cover a benign element while introducing an unsigned element containing manipulated identity claims that the parser processes.
The attack requires understanding how the service provider parses the SAML response: does it extract identity claims from the element covered by the valid signature, or from the first element matching a certain path in the document? If the parser and the signature validator disagree on which element is authoritative, the attacker can satisfy the validator while manipulating what the parser sees.
XSW attacks are not theoretical. Multiple SAML libraries across Java, Python, Ruby, and PHP ecosystems have been found vulnerable to XSW variants, and several major production systems have shipped with the vulnerability present. The attack requires careful construction of the XML but no cryptographic capability the attacker is manipulating document structure, not breaking signatures.
How to test: Introduce a duplicate assertion element with modified claims before or after the legitimately signed assertion in the SAML response. Observe which identity the service provider authenticates. A vulnerable SP will use the manipulated claims.
Misconfiguration 3: Audience Restriction Not Enforced
SAML assertions and OIDC tokens include an audience restriction a field specifying which service provider or resource server the assertion is intended for. The security purpose is clear: a token issued for Application A should not be usable to authenticate to Application B, even if both applications use the same identity provider.
The misconfiguration: service providers that do not validate the audience field in the assertion or token, or that accept assertions with no audience field as universally valid.
In an organization with multiple SAML service providers sharing an identity provider, an attacker who can obtain a valid SAML assertion for one application perhaps a low-security internal tool with weaker access controls can replay that assertion against a higher-security application if neither validates the audience restriction. The assertion is legitimately signed. The identity it asserts is real. The audience restriction that would prevent cross-application replay is simply not checked.
This misconfiguration is particularly common in organizations that implemented SSO incrementally, adding service providers over time, and where each application was integrated without a systematic review of which audience validations were in place. The identity provider may be correctly setting audience restrictions. The service providers are simply not checking them.
How to test: Obtain a valid SAML assertion for a low-privilege application. Replay it, unmodified, against a higher-privilege application in the same SSO federation. If authentication succeeds, audience restriction is not being validated.
Misconfiguration 4: Assertion Replay Without Nonce or Timestamp Enforcement
SAML assertions and OIDC tokens include timestamps NotBefore and NotOnOrAfter in SAML, iat and exp in JWT-based OIDC that specify the validity window for the assertion. They may also include a unique identifier that should prevent replay.
The misconfiguration: service providers that accept assertions outside their validity window, that do not track assertion IDs to prevent replay, or that implement the validation but with clock skew tolerances so generous they effectively disable the protection.
An assertion that can be replayed indefinitely is an assertion that an attacker who captures it once can use to authenticate as the corresponding user at any future time. The capture might happen through a compromised IdP log, through an XSS vulnerability that exposes the SAML assertion in the browser, through a compromised proxy, or through any other mechanism that gives the attacker access to a valid SAML response.
The nonce or assertion ID check prevents replay independently of timestamp enforcement: by recording every assertion ID that has been processed and rejecting any assertion whose ID has been seen before, the service provider ensures that each assertion is used exactly once regardless of its validity window.
Both controls should be present. Timestamp enforcement limits the window during which replay is possible. Nonce tracking eliminates replay even within the validity window.
How to test: Capture a valid SAML response during a legitimate authentication. Wait until the NotOnOrAfter timestamp has passed. Replay the assertion against the service provider. A vulnerable SP will authenticate the replayed assertion.
Misconfiguration 5: OIDC Token Validation Gaps
OpenID Connect builds on OAuth 2.0 to provide identity assertions through JWT-formatted ID tokens. The security of OIDC depends on the client validating the ID token before accepting the identity it asserts. JWT validation has a well-documented set of required checks: the signature, the issuer, the audience, the expiration, the issuance time, and the nonce if one was included in the authorization request.
Several specific JWT validation gaps appear consistently in OIDC implementations.
The alg: none variant: JWT signatures can theoretically use the algorithm none a special value indicating no signature. An ID token with alg: none in its header should be immediately rejected by any client. Libraries with permissive defaults or specific configurations may accept unsigned tokens if they are not explicitly configured to reject the none algorithm. An attacker who can produce a JWT with alg: none and arbitrary claims, and submit it to a vulnerable client, can authenticate as any identity without a valid signature.
Algorithm confusion: A JWT signed with an RSA key pair can be validated using the public key. Some libraries, when encountering a token claiming to use HMAC-SHA256 (HS256), will attempt to validate it using whatever key material is configured including the RSA public key used as the HMAC secret. An attacker who knows the server's RSA public key (which is often publicly available at the JWKS endpoint) can sign a JWT using the public key as an HMAC secret and claim it is an HS256 token. A confused library will validate it using the same public key and accept it as valid.
Issuer not validated: OIDC tokens include an iss claim specifying the identity provider that issued the token. A client that does not validate the issuer against its configured identity provider will accept tokens issued by any identity provider that the attacker controls.
How to test: For alg: none, produce a JWT with the algorithm set to none and an empty signature, then submit it to the token validation endpoint. For algorithm confusion, sign a token with the server's RSA public key using HMAC-SHA256 and submit it. For issuer validation, submit a token from a different issuer that you control. Any successful authentication indicates the corresponding validation gap.
Misconfiguration 6: JIT Provisioning Without Attribute Validation
Just-in-Time provisioning is a pattern where a new user account is created in the application the first time that user authenticates via SSO, without requiring prior manual provisioning. The application uses the identity claims in the SAML assertion or OIDC token email address, display name, group memberships, role attributes to create and configure the account.
The misconfiguration: applications that trust JIT-provisioned attribute values without validating them against the organization's expected attribute schema. An identity provider that allows attributes to be user-modifiable or an attacker who has compromised the assertion before it reaches the service provider can provision accounts with elevated privileges by including the appropriate role or group attributes in the assertion.
The attack pattern is specific: if the service provider assigns roles based on a SAML attribute like http://schemas.company.com/role and accepts the value administrator in that attribute as grounds for granting administrative access, any attacker who can influence the assertion content through misconfigured IdP attribute policies, through XSW manipulation, or through a compromised identity provider can provision themselves as an administrator on first login.
How to test: Submit a SAML assertion containing role or group attributes that map to elevated privileges in the application. If the JIT-provisioned account is created with those privileges, the attribute values are being trusted without validation against the organization's expected schema.
Misconfiguration 7: SSO Bypass via Legacy Authentication Paths
The final and often most impactful misconfiguration is not in the SSO implementation itself it is in the existence of authentication paths that bypass SSO entirely.
Organizations implement SSO to centralize authentication. But applications rarely start with SSO they start with native authentication (username/password, possibly MFA), and SSO is added later. The original authentication path does not always get removed when SSO is added. It gets disabled in the UI the login form disappears, replaced by a "Login with [IdP]" button. But the API endpoint that the form used to call is still there, still accepting credentials, still issuing sessions.
This is the SSO bypass. An attacker who knows the legacy authentication endpoint exists either from source code, from historical documentation, from a prior version of the application, or simply from guessing standard paths can authenticate directly without going through the identity provider. All the MFA enforcement, the conditional access policies, the audit logging, the session controls that the IdP provides: none of them apply to sessions established through the legacy endpoint.
The bypass is not always a complete credential authentication path. Sometimes it is:
An admin console with its own authentication that was set up before the SSO migration and never integrated An API key authentication mechanism that bypasses session-based authentication entirely and is not subject to the IdP's access controls A SCIM provisioning endpoint with weak authentication that allows account manipulation without IdP involvement A local user table that still exists and still works, accessible to anyone who knows to try it
How to test: Identify any authentication endpoint that is not the IdP-integrated login. Test whether it still accepts valid credentials. Test whether sessions established through it receive different security properties different session lifetimes, absence of MFA verification, absence of IdP-enforced conditional access policies.
Running a Complete SSO Security Audit
The seven misconfigurations above form a structured audit framework. Applied in sequence, they cover the highest-impact failure modes across both SAML and OIDC implementations.
For a SAML implementation, the audit sequence is: verify assertion signature validation (not just response signature), test for XSW variants by introducing unsigned duplicate assertions, verify audience restriction enforcement through cross-application replay, test assertion replay by submitting expired assertions and asserting IDs seen in prior valid assertions, and identify any authentication paths that bypass the SAML flow.
For an OIDC implementation: verify JWT validation completeness including the alg: none check, test algorithm confusion by signing with the RSA public key as HMAC secret, verify issuer validation, probe JIT provisioning by including elevated role attributes in an assertion, and identify legacy authentication paths.
For both: document every authentication endpoint in the application, including API key endpoints, admin consoles, provisioning endpoints, and any path that produces a session or token without going through the identity provider.
The Organizational Reality of SSO Misconfigurations
The seven misconfigurations in this post are not exotic. They are not the product of careless developers or negligent organizations. They are the product of complexity SSO integrations built under time pressure, using libraries with permissive defaults, in environments where the security testing that was specified in the project plan was deferred when the deadline arrived.
They are also the product of trust. SSO is positioned as the security layer, so when SSO is in place, teams tend to trust it. The assumption that SSO handles authentication means that the authentication security testing that would have been done on a native login flow is sometimes skipped. The integration is with a reputable identity provider, which creates the impression that the security has been handled upstream.
The identity provider is secure. The integration with the identity provider is not always secure. The difference between those two things is where every misconfiguration in this post lives.
SSO is infrastructure. Like all infrastructure, it is secure when implemented correctly and a liability when implemented incorrectly. The implementation correctness is not guaranteed by the identity provider's reputation or the protocol's design. It is established by testing the implementation against the specific misconfiguration patterns that appear most consistently in real-world assessments.
The seven patterns above are where to start.
Closing: The Perimeter Around the Gate
SSO centralizes authentication. That centralization is a security benefit when the SSO implementation is correct one secure path in is better than twelve inconsistently-secured paths. It is a security liability when the SSO implementation has gaps, because the centralization means all users flow through the same vulnerable path, and a misconfiguration that affects one user affects all of them.
The seven misconfigurations in this post are not the same as a broken door lock. They are the gaps in the fence around a gate that looks impressively secure. The gate itself may be fine. The SAML assertion signature validation, the audience restriction enforcement, the nonce tracking, the JWT algorithm verification, the JIT provisioning attribute validation, the legacy path decommissioning these are the fence. And the fence is what keeps the gate's security properties from being bypassed by someone who knows to look for a different way in.
The audit that tests the gate and ignores the fence has missed most of what matters.
Axeploit's authentication testing includes SSO-specific misconfiguration checks signature validation gaps, XSW variant testing, audience restriction enforcement, assertion replay, OIDC JWT validation completeness, and legacy authentication path enumeration. These tests run against the deployed application as an autonomous agent that navigates real SSO flows, captures and manipulates assertions in the process, and verifies whether the service provider's validation holds under the specific attack patterns that produce the most consistent findings in real-world SSO assessments.
