Add additional linking strategy for email and username to link only if user does not yet exist

Description

Add an additional linking strategy to reduce the risk presented by linking with a 3rd party IdP. The new linking strategy will be to link only if the user does not yet exist by email | username.

Currently we offer for email and username

Link on {value}. Create the user if they do not exist.
Link on {value}. Do not create the user if they do not exist.

This new option will be effectively:

Link on {value}. Only when the user does not exist.

Additional information

The purpose of this new strategy is to help mitigate account takeover risk. Risk is introduced when you do not completey trust the 3rd party IdP, or the 3rd party IdP does not provide adequate feedback on the state of verification a user's email address.

We could consider adding an additional setting to any IdP to force an email verification workflow to complete a link by email. Ideally this configuration would have three states:

Disabled. Do not perform additional email verification. Trust the identity provider to perform necessary verification.
Enabled. Always verify email address.
Enabled. Verify email address when a user with the linking email address already exists.

We may need to take into account email_verified from an OIDC provider, or optionally ignore this if we do not think the IdP is able to accurately represent the state of the email verification as is the case with Azure AD.

Auth0 has this forced email verification specifically for Azure AD, but I think it would be valuable for any IdP that may not completely trust, or when you know that the configuration allows for email related claims to be un-reliable. https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

In addition to account takeover risk, this would also address cross-contamination. If FusionAuth is being used to assert an owned email address via trusted social login (Google, Apple) and magiclink (no passwords, no phone) then a cross-link between addresses breaks that assertion. Users that have access to shared inbox might have different permissions when asserting the shared inbox email than when asserting their corporate or personal email. Being able to block attaching a non-matching link restores the trust in the assertion of the user email being sent to the application.

Navigation Menu

Repository navigation

Add additional linking strategy for email and username to link only if user does not yet exist #2424