A lot has changed in the authentication system since 2017. The main thing is that users can connect/disconnect accounts whenever they want.
As I understand it, this change was added to protect against:
User connects google account 00001, with email user@example.com, to their discourse account
User tries to log into discourse using google account 00002, with email user@example.com
Error is shown, must be resolved on the console
Under the new “ManagedAuthenticator”, this would happen:
User connects google account 00001, with email user@example.com, to their discourse account
User tries to log into discourse using google account 00002, with email user@example.com
User logged in, reference to 00001 is scrubbed and replaced with 00002
I believe this is also the same method we follow with core Discourse SSO.
This seems fine to me. If a user is in control of a google account with a matching email address, then we should trust them. Was there a specific attack vector you were trying to protect against with this error message, or can we go ahead and make it match the other authenticators?
But in that case they could just resend their password and log in that way instead of using OAuth?
This change feels user-hostile, in our corporate environment, the scenario (user leaves company, email is deactivated; user is re-hired and email is re-instanced) is relatively common when we hire freelancers.
“Deactivated, don’t know how our IT-department implements that, might be that they delete the google account”
We just encountered this yesterday and I found this recent thread, wanted to share my feedback
Yeah, the protection here is certainly more ‘cautious’, but as @bas says we put so much trust in email=identity elsewhere that I think it’s fine to clean things up automatically. I’ll be migrating Google over to the new system this week so will make this change.
Also, note that @supermathie’s change was made well over a year ago - I just bumped a very old topic. Things have changed a lot in our authentication system since then.