3

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 user@example.com, 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?

1 Answer 1

1
+100

... 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 ("victim@gmail.com", "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 "firstNamelastName@gmail.com" and "firstName.lastName+company@googlemail.com" 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.

2
  • Would you agree that these concerns are mitigated if the website verifies email addresses when it creates new non-SSO accounts? E.g. if when creating an account using "firstName.lastName+company@googlemail.com", the site requires the user to click a verification link sent to that address, then only someone with access to the canonical address at GMail is going to be able to complete account setup, and an attacker cannot pre-create an account to link with SSO later. Mar 29 at 19:52
  • I accepted this answer because I think it outlines some valid concerns, but I think they are fairly easily mitigated, and the ad-hoc SSO linkage I describe is probably feasible from a security standpoint. Apr 1 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.