feat: add DangerousSSOAutoLinking config flag for automatic SSO ident…

[yuvalkarmi]

What kind of change does this PR introduce?

Feature: Add optional GOTRUE_SECURITY_DANGEROUS_SSO_AUTO_LINKING config flag to enable automatic identity linking for SSO providers.

What is the current behavior?

SSO identities are always isolated - they always create new user accounts even when the email matches an existing verified user. This was intentionally implemented in PR #1098 for security reasons.

Related discussion: https://github.com/orgs/supabase/discussions/42144

What is the new behavior?

When GOTRUE_SECURITY_DANGEROUS_SSO_AUTO_LINKING=true is set:

• SSO identities join the "default" linking domain (same as OAuth providers)
• SSO users are linked to existing accounts based on verified email matching
• Enables seamless migration from email/password or OAuth to SSO without duplicate accounts

When disabled (default): No behavior change - SSO remains isolated.

Additional context

Why "dangerous" in the name?

• The IdP controls which emails are considered "verified"
• A malicious/compromised IdP could claim any email and link to any account
• Only safe when you trust the IdP to verify email ownership

Use case: Organizations with existing users (email/password or OAuth) want to enable SAML SSO without creating duplicate accounts or building custom migration flows.

Files changed:

• internal/conf/configuration.go - Add config flag
• internal/models/linking.go - Check flag in GetAccountLinkingDomain()
• internal/models/user.go - Pass flag to IsDuplicatedEmail()
• internal/models/linking_test.go - Add 4 new tests
• Updated all callers of IsDuplicatedEmail()

[depthfirst-app]

🟠 Severity: HIGH

Authentication Bypass via Malicious SSO IdP: When DangerousSSOAutoLinking is enabled, SSO providers automatically trust the IdP's email verification (hardcoded EmailVerified = true in samlacs.go). A compromised or malicious SAML IdP can claim ANY email address and automatically link to/takeover existing accounts. Unlike globally trusted OAuth providers, SSO IdPs are customer-configured and may lack proper email verification controls.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: This is a complex architectural security issue that requires multiple complementary mitigations:

1. Implement an SSO Provider Allowlist: Add configuration to explicitly specify which SSO providers are trusted for auto-linking (e.g., GOTRUE_SECURITY_SSO_AUTO_LINKING_ALLOWED_PROVIDERS). Modify GetAccountLinkingDomain() to only return 'default' for SSO providers that are on this allowlist.

2. Add Account Linking Confirmation Flow: Before completing the account link, send a confirmation email to the existing account's verified email address with a time-limited token. Only complete the link after user confirmation. This requires changes to the DetermineAccountLinking flow and new database tables for pending links.

3. Implement Enhanced Logging and Alerting: Add comprehensive audit logging for all SSO auto-linking events, including the IdP identifier, email being linked, and user IDs involved. Configure alerts for suspicious patterns (e.g., multiple linking attempts, links to privileged accounts).

4. Multi-Factor Attribute Matching: Beyond email matching, require additional IdP-provided attributes to match (e.g., name, employee ID) before allowing auto-linking. Add configuration for required matching attributes.

5. IdP Certificate Validation: Ensure SAML signature validation is enforced and add monitoring for certificate changes on SSO providers to detect potential compromises.

These changes span multiple files (linking.go, configuration.go, samlacs.go, audit logging system, and database migrations) and require careful consideration of backward compatibility and migration paths for existing deployments.