Single Sign-On - This Backdoor Survives Offboarding

What happens when your application quietly creates a local account when a user logs in with Single Sign-On (SSO)? PureCyber found a subtle but dangerous logical flaw that turns legitimate SSO users into permanent insiders.

Modern applications and businesses are both big fans of SSO, and it’s not difficult to see why. It’s convenient, reduces password fatigue, and lets your identity provider handle multi-factor authentication. What could possibly go wrong?

Quite a lot, it turns out.

During penetration testing as part of a recent security assessment, we discovered a classic example of a logical race condition that most development teams don’t consider. The application in question supported both local username/password authentication (with multi-factor authentication enforced) and enterprise SSO.

On the surface, everything looked secure. Under the hood, it was quietly creating a persistent backdoor.

How the attack works, step by step

1) First login via SSO

An employee clicks “Login with Microsoft” (or Google, etc.) to a public-facing application. That application receives the user’s email address from the identity provider and creates a local user record in its database, using that email as the username.

2) The password reset trapdoor

The that same user goes to the login page, selects the traditional “Username + Password” option, and clicks “Forgot password?”. Because the email address now exists in the local user table, the application happily sends a password reset link.

3) Local Credentials Created

The user sets a password. The account now has two supported authentication methods, both the SSO method and the newly created local credentials.

4) The Offboarding Moment

Months later, the employee leaves the company. The security team does everything right: they disable the user in the corporate IDP, revoke all SSO tokens, and confirm the employee can no longer log in via SSO.

Except the employee can still login. Because a local password had already been established, the former employee could continue to log in to the application using the local username (their old work email) and password combination they set up in step 3.

Doing so unintentionally granted that person ongoing access to organisational data (customer data, financial records, or internal tools), even after their account was properly removed from the corporate identity system. 

The offboarding process was technically perfect, yet should that same leaver try and login to the same application, they would be granted access.

Why does this happen?

This issue arises when SSO-provisioned accounts are not distinctly flagged or isolated from local authentication pathways.

Most applications store the SSO email as the primary username when they provision the account. They don’t store a separate, opaque identifier (such as a UUID or the SSO sub claim). Because there is no flag marking the user as “SSO-only”, the password-reset flow treats them exactly like any other local user.

It’s not a coding bug in the traditional sense. It’s a contextual logic failure where the application loses track of how the user was originally created.

What’s the real-world impact?

This flaw both reduces the effectiveness of the offboarding processes and undermines it significantly. At the same time, it increases the likelihood that former employees, contractors, or other users who were only intended to have temporary SSO access can retain persistent access to the application long after their known access was revoked. This can mean:

• Ex-employees retaining access for months or years

• Contractors or partners who were only supposed to have temporary SSO access keeping a permanent key

• Compliance violations (GDPR, SOC 2, ISO 27001) around proper user lifecycle management

• Increased blast radius in the event of a credential leak

The ramifications of unchecked access on this level aren’t worth ignoring; unauthorised data access, reputational damage, and compliance failures are all very possible outcomes. What’s more, we’ve seen this pattern already in multiple SaaS platforms, internal tools, and even customer-facing portals, making it worthy of attention of anyone that uses SSO for their applications.

Key takeaway for developers and security teams

While it can add a layer of useful protection to your applications, it’s important to acknowledge that SSO doesn’t magically solve identity and access management problems, and actually moves some of them into the integration layer. Every time your application creates a local record from a federated login, it’s worth asking yourself:

“What happens if this user is removed from the identity provider tomorrow?”

If the answer is “they can still log in”, you have the same vulnerability we found.

At PureCyber, we specialise in identifying and dealing with contextual and logical issues just like this; the ones that pass every automated scan and every traditional penetration test, yet still represent a significant business risk.

If your organisation relies on both SSO and local authentication, we strongly recommend testing for this pattern. It takes no time at all to verify and the required changes to remediate are typically straightforward once identified.

PureCyber is here to assist

If you need advice or assistance with testing for this SSO vulnerability, or to discuss any other application security matters, the PureCyber team is ready and waiting to support you.