I understand your frustration. We're thinking about ways to ameliorate this issue.

And you aren't alone. Here are a couple of open github issues:

• https://github.com/FusionAuth/fusionauth-issues/issues/751 (kind of the reverse of what you're talking about, but related)
• https://github.com/FusionAuth/fusionauth-issues/issues/1 (the very first issue filed!)

Please feel free to upvote them, as that helps direct our development efforts. If these issues don't cover what you're looking to do, please do file a feature request with use case specifics.

Thanks,
Dan

Currently if I create an account for a user with the provided email address (creating registrations, roles and matching account on our backend) and they connect via SSO on a different email account - FusionAuth creates a second account for them even when we have auto registration turned off. That account doesn't have the access we promised even when they can authenticate with it. To fix the problem I can't go in and fix the original account since there will now be an email address collision on the system. Requires deleting the system generated account first, then the email can be changed. This hassle trickles up into our admin screens as well since accounts are really created there and not directly in FusionAuth. When the email address update runs into a collision with an existing account we need to query FusionAuth for app registration counts - if zero it might be safe to delete the conflicting account then proceed with the renaming. But this feels unnecessarily complex.

Currently the resolution is simply by email (there may be some enhancements in the future).

So in your scenario, if you log in with richard@piedpiper.com and then later log in with a Google account that has the email address richard@piedpiper.com - it will be the same user in FusionAuth.