Executive Summary
The Obsidian Security Research Team has uncovered a persistence attack vector, Shadow Linking, which allows threat actors to gain persistent access to victims’ SaaS accounts via OpenID Connect (OIDC) login. Employees may also abuse this technique to maintain persistent access to company resources even after their offboarding. Many applications lack adequate defenses against such attacks, posing significant challenges for both individuals and organizations. This issue affects several popular SaaS applications, including but not limited to OpenAI, Zoom, Slack, Atlassian, Twitter, Expensify, and Notion.
Background
Numerous SaaS applications have adopted Single Sign-On (SSO) services for their authentication flows. Social identity providers (IdPs) such as Google, Apple, Microsoft, and Facebook are broadly trusted because of their widespread adoption.
However, our research shows that applications often incorrectly integrate with these IdPs, undermining the security of these SaaS applications. There are two key reasons for this:
Arbitrary Email Address Registration on IdPs
Many enterprises underestimate how easily organizational email addresses can be registered with almost any identity provider. For example, an email address managed on Google Workspace can still be used to register with other identity providers like Apple and Microsoft.
Personal email addresses managed by one identity provider can also be used to register accounts on another. For instance, a Google email address (e.g. gmail.com) can be used to register an Apple account and a Microsoft email address (e.g. outlook.com) can be used to register a Google account.
In fact, you can register on any of the common identity providers using almost any email address, regardless of its origin. The registration process typically requires only a one-time proof of possession, such as presenting a verification code sent to the email.
OpenID Connect
OIDC is an authentication protocol built on the OAuth 2.0 framework (RFC 6749). As one of the most widely implemented SSO protocols, OIDC is utilized by numerous identity service providers and integrated into a myriad of applications to facilitate third-party authentication.
OIDC primarily secures the user authentication process by enabling applications to authenticate users through third-party IdPs such as Google. Upon successful authentication, the IdP issues an ID Token containing the user’s basic information to the application. This token serves as proof of the user’s identity. However, it does not specify how applications should use the ID Token for user identification and account linking. The application bears the responsibility for mapping the received ID Token to the corresponding internal user accounts.
Discrepant Dependency on ID Token Claims
An ID Token, issued by identity providers in JSON format, contains multiple claims that convey the user’s basic information, such as name, ID, and email address. Applications leverage these claims to authenticate end-users. A typical ID Token issued by Google’s identity service exemplifies this structure.
However, despite OpenID Connect emphasizing that applications should uniquely identify users using the sub claim (a unique identifier for a third-party account), as defined:
“The sub (subject) and iss (issuer) Claims from the ID Token, used together, are the only Claims that an RP (relying party) can rely upon as a stable identifier for the End-User. All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users.”
This approach is not always honored and widely adopted by applications.
Shadow Linking
Many applications, such as OpenAI, rely on the email claim to uniquely identify users and link user accounts. To put this into perspective, consider a user with an OpenAI account registered with an email address (victim@domain.com). If a shadow social IdP account, such as Apple, is created using the same email address (victim@domain.com), and this Apple account is used to authenticate to OpenAI via Apple’s OIDC login, it will authenticate as the same account without requiring additional verification. This shows that the Apple account is automatically linked to the victim’s OpenAI account.
From this observation, we concluded that regardless of which third-party identity service the user signs in from, as long as the email address of the third-party end-user matches one of the internal accounts, OpenAI links and merges the third-party end-user with that internal account without any further verification. This behavior is observed in many applications.
This is problematic. Consider two scenarios where this behavior can pose significant security risks:
- Email Account Compromise: A threat actor compromises a user’s Gmail account and registers accounts on Apple, Facebook, Microsoft, and other IdP providers using their email address. Since these third-party accounts are completely managed by the threat actor, and email verification only happens once during the registration, the threat actor can leverage these accounts to access all the victim’s resources, both personal and organizational. This access persists even after the threat actor loses control of the victim’s email. This poses a more severe threat than abusing account linking features within individual SaaS applications, as it doesn’t require compromising the SaaS account itself. Moreover, it enables the takeover of future SaaS accounts that the victim may create, even ones that do not currently exist.
- Organizational Member Abuse: A Google Workspace organizational member can register accounts on Apple, Facebook, Microsoft, and other IdP providers using their organizational email address. These third-party accounts are managed entirely by the user, not the organization, and email address verification occurs only once during the registration process. This enables the organizational member to utilize these accounts to access the organization’s internal resources across various applications, even after they have left the organization.
An application granting an account session to a third-party end-user based merely on an email address without additional verification is what we call Shadow Linking. Based on our tests, Shadow Linking happens almost everywhere. One compromised third-party account can act as a skeleton key, “shadow linking” to numerous applications, working perfectly in terms of persistence.
Test Cases
During our research, we tested nine different popular applications, both individual and enterprise versions, assuming they use OIDC authentication (which they do by default).
Our observation reveals that 7 out of 9 applications are vulnerable to Shadow Linking. The test results are summarized below:
| Application | Identification Claim | Vulnerable to Shadow Linking (without 2FA by default) | Vulnerable (with 2FA enabled) / 2FA Bypass | Set 2FA Without Extra Verification | Manage IdP Links (disable or occupy) | Modify Email Address | Cost to Enable SAML SSO |
| Zoom | ☠️ | 🚫(basic) 👍(pro-) | 🚫(basic) 👍(pro-) | ☠️ | 👍 | $21.99/month/user | |
| Notion | ☠️ | ☠️ | 👍 | ☠️ | 👍 | $15/month/user | |
| Atlassian | ☠️ | ☠️ | 👍 | ☠️ | 👍 | $11.75/month/user | |
| Slack | ☠️ | 👍 | ☠️ | ☠️ | 👍 | $15/month/user | |
| OpenAI | ☠️ | ☠️ | ☠️ | ☠️ | ☠️ | $60/month/user | |
| Expensify | ☠️ | ☠️ | ☠️ | ☠️ | 👍 | $9/month/user | |
| X | ☠️ | 👍 | 👍 | ☠️ | 👍 | 🚫 | |
| GitLab | Sub | 👍 | 👍 | ☠️ | 👍 | 👍 | 👍 |
| Shopify | Sub | 👍 | 👍 | ☠️ | 👍 | 👍 | 👍 |
Legend:
☠️ – Vulnerable
👍 – Secure
🚫 – Not Available
(basic) – Applies to Zoom’s basic subscription
(pro-) – Applies to Zoom’s pro subscription and higher
Enforcing SAML SSO is the best practice to defend against shadow linking in the enterprise environment. However, SAML SSO is often only available as part of “Enterprise” pricing in applications. According to the “SSO tax”, vendors can charge 2x, 3x, or 4x the base product pricing for access to SSO, which disincentivizes its use by small businesses and makes them more vulnerable than larger companies.
We also explored the possibility of evading defenses and incident responses once shadow linking has occurred. Our findings reveal that many applications lack effective measures to actively defend against or mitigate the impact of shadow linking once it has been established. This gives the attacker opportunities to permanently dwell and even lock out the victim once the attacker creates their initial foothold. We will discuss this further.
2FA Bypass
Two-factor authentication (2FA) is intended to add an extra layer of security to applications. However, many applications place complete trust in third-party identity services and do not apply 2FA to SSO logins, even when users have enabled it. Based on our test results, 5 out of 7 vulnerable applications disregard 2FA when a user signs in via SSO. This oversight leads to serious security issues, allowing attackers to evade defensive mechanisms and maintain persistent access to the victim’s account.
For example, Atlassian explicitly states that two-step verification is not applied to third-party SSO logins.
Other vulnerable applications such as OpenAI, Notion, and Expensify, also ignore the 2FA policy for third-party sign-ins.
Moreover, our test cases revealed that all vulnerable applications lack the functionality to unlink or disable a third-party account. This, combined with the 2FA bypass, provides attackers with a means to establish permanent persistence on the victim’s accounts once the attack occurs.
2FA Abusing
Our research also found that many applications do not require additional verification when setting up 2FA, as observed in our test cases with Slack, OpenAI, and Expensify. This insufficient verification allows threat actors to abuse 2FA to gain exclusive control over the target account, effectively locking out the legitimate user.
For example, OpenAI’s products, including the highly popular ChatGPT and its API platform, are vulnerable to both Shadow Linking and Multi-Factor Authentication (MFA) lockout attacks. OpenAI implements 2FA in a way that once 2FA is enabled, users must log in using the same third-party authentication method used during the 2FA setup. The setup process only requires verification of the currently signed-in third-party account, which is inadequate and creates a false sense of security.
As a result, attackers can easily exploit this feature to enable 2FA, thereby disabling all other authentication methods and achieving a full account takeover, leading to complete victim lockout.
Can users simply use their phone number or email address to recover the account? Unfortunately, OpenAI is phasing out phone verification and experiencing issues with email delivery. Furthermore, it is impossible to change the email address linked to the account. As of today, there is no way to recover an account once it has been taken over in this manner.
Detection
While detection is challenging, the blue team can still obtain valuable information from the user’s login activity logs. By analyzing the metadata from login events—such as the authentication method (password, OIDC, SAML SSO, etc.), the third-party IdP used, the IP address and the timestamp—the blue team can identify malicious activity by correlating these details with other compromises and events.
Through our research, we found not all vulnerable applications provide comprehensive logs to support detection. For example, Slack only provides access logs that describe the user login activity without details like login type and SSO sources. Other applications, such as Atlassian, do not even offer login-related activity logs. The lack of detailed login logs makes it hard to even have visibility into Shadow Linking.
Obsidian Recommended Remediations
For Application Developers
- Link Third-Party Accounts Based on the Sub Claim
When an ID token with an email address that matches an existing account is presented for the first time, require the user to authenticate the existing account first or prompt the user to link the account through the user portal, rather than automatically linking and merging the third-party account with the existing account. Once authenticated, bind the account with the sub claim in the ID Token. This process ensures that the current user from the third-party service is indeed the legitimate owner of the account. Applications like GitLab and Shopify implement this method to effectively defend against Shadow Linking from the outset.
- Provide Comprehensive Third-Party Linking Management
Enhance security by giving users transparency and complete control over the SSO linking process, including the ability to unlink third-party accounts and disable certain third-party sign-ins in both individual and enterprise setups. Our test cases showed that only 2 out of 9 applications offer sufficient functionalities to mitigate the Shadow Linking attack.
- Apply 2FA to Third-Party Sign-In
When users enable 2FA, applications should also enforce 2FA for third-party sign-ins. This measure mitigates the Shadow Linking attack and addresses further 2FA abuse and bypass threats.
- Require Additional Verification Before Setting Up 2FA
Ensure that additional user verification is required when setting up 2FA through the user portal. This extra step confirms the user’s identity and mitigates 2FA abuse attacks.
- Support Detailed Login Logs for Security Audit
Ensure detailed login event metadata is recorded, including the authentication method (password, OIDC, SAML SSO, etc.), the third-party IdP used, the IP address and the timestamp.
For End-Users
End users should take proactive measures to mitigate the potential impact of Shadow Linking.
- Enforce 2FA
Enable two-factor authentication (2FA) on all accounts where possible.
- Set Up a Password
Setting up a password for an account can provide additional security similar to enabling 2FA. For instance, if you sign up for a Zoom account using an SSO option like Google, your account will not have a password by default. Setting up a password ensures that many operations, such as linking with a third-party account or enabling 2FA, require extra verification.
- Disable or Pre-link Third-Party Sign-In Accounts
Remove unused or unnecessary third-party sign-in options or pre-link owned third-party accounts to reduce attack vectors.
For IT Administrators/Corporate Security
- Enforce SAML SSO Authentication
Implement SAML SSO authentication across all work applications. This centralizes the management of employee accounts and prevents external users from infiltrating application workspaces. It also reduces the burden on IT administrators to manually delete users’ accounts in various applications after off-boarding.
- Disable Unused Third-Party Sign-In Options
Disable any unused third-party sign-in options to block external users from joining the workspace.
- Enforce 2FA Policy on Managed Accounts
Ensure that all managed accounts have 2FA enabled wherever possible.
- Enforce Password Setup on Managed Accounts
Ensure all managed accounts have passwords set up, which can function similarly to 2FA authentication and provide additional security.
For Identity Service Providers
- Add Domain-Related Claim into ID Token
To prevent external third-party users from infiltrating organizational workspaces, identity service providers should support domain-related claims in their ID Tokens. This helps applications differentiate between personal and organizational users, similar to the hd claim supported by Google Identity services.
- Reject Work and Education Email Address Registration
Disallow the use of work or education email addresses for account registration. For instance, Microsoft and Apple already block account registration with many email addresses from major companies and renowned educational institutions.
Given the challenge of blocking all work or education email addresses for account registration, identity service providers should offer organizations a way to declare their domain addresses and specify whether their domain email addresses can be registered. For example, Apple ID could create a website where organizations can manually prove ownership of their domain by setting up a TXT DNS record and notifying Apple if users are allowed to register accounts with this domain.
Conclusion
The rise of SSO services has streamlined user authentication across numerous SaaS applications. However, as our research highlights, relying on these services can introduce significant security risks.
Application developers must adopt robust security practices, such as linking accounts based on the sub-claim and providing comprehensive third-party linking management. End-users must remain vigilant, enabling 2FA and managing their third-party links appropriately. IT administrators should enforce stringent security policies, including SAML SSO authentication and 2FA policies, to safeguard managed accounts. Identity service providers also have a vital role to play by offering domain-related claims and rejecting the registration of work and education email addresses.
By implementing these measures, we can collectively enhance the security of SSO integrations and protect against the persistent threats posed by Shadow Linking.