Risks in Merging SSO and Non-SSO Identities

In Descope, a user identity can be associated with one or more authentication methods.

All non-SSO methods—such as password, magic link, OTP, or passkey—can share the same login ID (typically an email or phone number), allowing a single user to authenticate through multiple non-SSO methods seamlessly.

However, SSO-based authentication works differently. When a user logs in via SSO, their identity is tied to the unique tenant ID (associated with their external SSO IdP), which differs from their regular login ID (e.g., email). As a result, logging in with both SSO and non-SSO methods can result in separate user records unless explicitly linked.

While it may seem convenient to let a user sign in through both SSO and non-SSO methods, doing so without proper identity linking can introduce significant security, compliance, and identity management challenges.

Why Mixing SSO and Non-SSO Is Problematic

SSO is designed to be a centralized, organization-controlled authentication mechanism. When a user signs in with SSO (e.g., Google Workspace, Microsoft Entra, Okta), their access is governed by your identity provider (IdP), often with additional policies like MFA, session control, group-based access, and more.

Allowing that same user to bypass SSO using an alternative login method (like password, OTP, or magic link) introduces serious risks:

1. Bypassing Enterprise Controls:

If an attacker gains access to the user's email or weak password, they could log in outside the organization's SSO and bypass:

Enforced MFA
Conditional access policies
Session or device restrictions

2. Loss of Central Revocation:

Revoking access via the IdP (e.g., deactivating the employee in Google or Entra) becomes ineffective, as the user could still log in via the non-SSO path.

3. Audit and Compliance Confusion:

Split identities and inconsistent authentication paths lead to:

Fragmented audit trails
Complications in identity governance or SCIM provisioning

4. Unintended Account Takeover:

If the same user email is used for both SSO and non-SSO flows, automated login mechanisms may create unexpected outcomes. For example, a user expecting to log in via SSO may accidentally create a non-SSO account if fallback flows aren't tightly controlled.

How Descope Handles SSO Users

In Descope, SSO users are distinct identities linked to their SSO provider configuration. When a user logs in via SSO, Descope identifies them using the IdP metadata and assigns them a user ID specific to that SSO flow.

By default, Descope does not merge SSO users with identities created through other authentication methods (e.g., email, phone, social logins). This separation ensures:

Consistent login behavior
Alignment with your IdP policies
Safer session management
Easier identity isolation for auditing and access reviews

Even if a user signs in using the same email address via SSO and via a non-SSO method, they will be treated as separate users in Descope unless explicitly linked (which is not recommended).

In rare scenarios, you may want to enable fallback login methods for specific users such as tenant or organization administrators, in case the configured SSO (Single Sign-On) provider becomes temporarily unavailable or misconfigured.

By default, if SSO is enforced, users are only permitted to authenticate through the configured SSO provider. However, when SSO is not enforced, users can authenticate using any supported method (e.g., OTP, magic link, password), including the fallback options.

Was this helpful?

On this page