Adding SSO to an existing website - should SSO login link to matching email address?

Question

I am adding Single Sign-On (SSO) via Google and Microsoft identity providers to a web application where many thousands of user accounts already have existing credentials stored by username and password. Each account also has a primary email address separate from its username. Users can reset their passwords by requesting a link sent to the primary email address. Therefore, as with most web applications, access to the account's email address effectively grants access to the application.

In this context, would it be good practice to log users into their accounts after a successful SSO authentication based solely on the email address returned by the SSO response's OAuth claims matching the email address of an active account?

Note that we will also offer a feature allowing existing users to explicitly link their accounts to SSO via Google or Microsoft using the permanent unique OAuth 2.0 Subject ID. This will be done after successful login using their legacy credentials. By contrast, my question above is about whether to allow an ad-hoc SSO login to an unlinked account based on a matching email address. The obvious advantage to this is convenience: users will not need to take an extra step after the SSO login to enter their existing credentials for my application. But I can also think of some potential drawbacks:

• If a user successfully authenticates via SSO, say to a Google account for [email protected], the user does not necessarily control that email address (particularly if it's a non-GMail address.) So I could be granting access to my application to an unauthorized user. This seems unlikely but theoretically possible.
• If the user changes their email address, either in my application or at their SSO provider, we could lose the ability to match. Of course, this would be resolved by explicitly linking the SSO account as described above.

I have found that there is far less guidance on integrating SSO providers with existing legacy websites than there is on integrating SSO when building websites from scratch!

Edit: Further background on email verification in SSO - I noticed that the Google JWT response includes an email_verified boolean claim that is always true. It appears that this is part of the standard OpenID Connect specification and indicates that the user controls the email address. Microsoft's SSO implementation has a similar (optional?) claim. I assume that if this claim is true, my application could be confident in granting access to any account matching the email address, right?

Answer 1

I can think of only 3 situations

1) Attacker creates account with your email before you try to sign up with SSO

• In this case when I am trying to link SSO to the existing account I check if email of that account is verified, if not then I reset it's password, link the SSO and then I set the account as verified. This way attacker has no longer access to the account.

2) What in case that attacker tries to create SSO (e.g. FB) and then link it to the app where victim later would like to create account ?

• during victim's signup he/she will be warned that such account already exists, but simple password reset would grant access. So then attacker has access to victim's data on that platform.
• in this case you can force all SSO registrations to contain email_verified=true claim in id_token. It really depends on those 3rd party SSO providers if they require email verification before providing you with SSO capabilities. E.g. Google SSO is always verified because Google SSO account=email.

3) Existing account and newly created SSO by attacker

• again, check email_verified=true in SSO and link account only when true

Regarding dots and plus signs in email, simply ignore the functionality behind them. So [email protected], [email protected] or [email protected] are separate entities. Then in-app you can make an option to link different SSO to existing account and thats basically it.

Answer 2

... whether to allow an ad-hoc SSO login to an unlinked account based on a matching email address.

Just like you, I'm not aware of any authoritative guidelines on how to integrate SSO for existing accounts, but I would argue against doing this for several reasons.

I haven't seen you mention the possibility of an attacker preparing a victim's account beforehand. A possible scenario might start out with an attacker creating an account with an email/username-password combination ("[email protected]", "password") beforehand. If the victim remains unaware/unwarry, and starts using the account using SSO at a later date, the attacker retains access to the victim's account using the email/username-password combination. There are a bunch of conditions that have to be met for such an attack to actually succeed, but it's far from impossible.

I think a much stronger and more practical argument against this, is that multiple email addresses values can map to a single inbox. For example, for gmail users, there's no difference between @gmail.com and @googlemail.com, users can add arbitrary dots in the local-part, anything after a + in the local-part is ignored, etc. For example, both "[email protected]" and "[email protected]" point towards the same inbox. Most users probably don't use these features when signing up for an account, but there's definitely a small portion that does.

So, without any changes, trying to match email addresses against your database is likely going to be an expensive operation. You could "canonicalize" each email address to handle this, but are you confident that you are gonna be able to handle all these cases properly? What if an attacker makes a second account with the same canonical email address, and when the victim connects using SSO, your algorithm matches with their account instead of the real account? How will we deal with this, and what's next? I feel like things are quickly spiraling out of control.

I don't think it's impossible to eventually come to a solution that could be secure, but it really seems like you're opening a can of unwanted complexity worms with this one. I would keep it simple, and let existing users add SSO only after logging in successfully with their username-password combination.