Identity Provider Flaw Led to Account Takeovers on SaaS Platform

The Premise of Trust: Identity Providers and Single Sign-On

Single sign-on (SSO) relies on a fundamental premise: when a user arrives from a trusted identity provider (IdP), that provider has already vouched for their identity. This allows platforms to bypass traditional password prompts and grant immediate access. The implicit agreement is that the IdP has done the heavy lifting of authentication, and the relying party can trust that assertion. However, a critical vulnerability exploited a gap between trusting the IdP to authenticate its users and trusting whatever information the IdP asserts about those users. This distinction became the chink in the armor, enabling account takeovers.

The platform in question supported federated connections, allowing tenants to integrate with their corporate IdPs via SAML or OIDC. When a user initiated a sign-in through one of these federated channels, the IdP would post back an assertion containing user details. The platform's server then faced a single, crucial question: which local account on our system corresponds to this asserted identity?

Getting this mapping wrong had immediate and severe consequences. An incorrect mapping could either lock a legitimate user out of their own account or, far more dangerously, grant unauthorized access to an attacker who had impersonated a valid user. The vulnerability hinged on how the platform used the email address, a common identifier, as the sole 'join key' for this mapping process.

The Weak Link: Email as the Sole Join Key

The core of the vulnerability lay in the platform's reliance on the user's email address as the definitive identifier for mapping federated identities to local accounts. When a user signed in via SSO, the IdP would send an assertion that included the user's email address. The platform's server would then query its internal database to find a local account associated with that email. If a match was found, the user was logged in as that account.

This approach appears straightforward: the IdP says, "This is user X, and their email is Y," and the platform finds the local account for email Y. The problem arises because an email address, while often unique and a strong indicator, is not an immutable, cryptographically verifiable proof of identity in the same way a signed assertion from an IdP might be. It is merely a claim made by the IdP.

Consider a scenario where an attacker could trick a legitimate user's IdP into asserting a different email address, or perhaps an attacker could register an email address that was previously used by a legitimate user but is now disassociated from their account. In the context of the platform's logic, if an IdP asserted that a user's email was 'attacker@example.com', and the platform found an existing account linked to 'attacker@example.com', it would grant access to that account. The platform trusted the IdP's assertion about the email address without sufficient cross-verification or context.

The vulnerability was not that the IdP was compromised, but that the platform's interpretation of the IdP's assertion was too simplistic. The IdP correctly authenticated a user and provided their associated email. The platform then blindly trusted that email as the definitive link to a local account, overlooking the possibility that the email itself could be misrepresented or that the mapping logic was too brittle.

Exploiting the Mapping Gap

The exploit worked by manipulating the mapping process. An attacker could potentially register an account with a specific email address on the target platform. Later, if a legitimate user with the same email address (perhaps one who had recently changed their email or whose account was previously associated with that address) attempted to log in via SSO, the system would look for the existing account tied to that email. If the attacker's account existed and was somehow prioritized or if the mapping logic had a flaw, the attacker's account would be associated with the legitimate user's SSO session.

More critically, the issue wasn't about the IdP itself being tricked into issuing a false assertion about who the user was. Instead, the flaw was in the relying party's (the SaaS platform's) internal logic for associating that assertion with a specific local user account. The IdP vouched for a user's authentication, but the platform misinterpreted the data within that vouch to misattribute the identity.

Imagine an IdP that correctly identifies User A, who has the email 'user.a@company.com'. The IdP sends an assertion. The platform receives this assertion and looks for a local account mapped to 'user.a@company.com'. If the platform's mapping logic is flawed, it might incorrectly link this assertion to User B's account, or worse, to an account controlled by an attacker who previously held the 'user.a@company.com' email address.

The specific bug, as described, lived in the gap between "trust the IdP to authenticate its own users" and "trust whatever the IdP tells you about who its users are." These are distinct levels of trust. The first is about verifying credentials. The second is about trusting the integrity and accuracy of all attributes provided within the authentication assertion, especially when those attributes are used as direct keys for account association.