4

Context

I've read somewhere that one should not match by email (e.g. the email given by the Google JWT token) when using SSO (e.g. OpenID Connect) but it's not clear to me why.

The recommended approach seems to be using aud and sub claims or other similar combinations but this has obvious drawbacks: for example if a user logs in with Google and then after a few months, not remembering which SSO provider it used, it logs in with Facebook, with the same email, then a new account will be created; if we were matching by email address instead the two accounts would be effectively linked.

Question

Assuming access to the email should grant access to the application, what are the downsides of matching users by the email provided by a SSO provider (assuming email_verified is true)?

Improve this question
10
  • 2
    aud is not relevant here, it should always be checked to help avoid the Confused Deputy Problem. sub is the user id at the issuer, Google itself clears out (in its doc) that sub is stable, the e-mail is not. If you use the e-mail you may not match even for the same IdP. Regarding using a different IdP with the same e-mail, that's a form of federation of accounts. Allowing a match by e-mail is a security risk because you don't know if the IdP verified that e-mail or if that accounted was leaked. But can also turn out to be handy, so you may want to implement a federation process
    – Margaret Bloom
    Commented Sep 30 at 10:26
  • 1
    where when not founding the sub but a matching e-mail you make the user verify the e-mail. This assuming it's the e-mail that proxies the identities of your users (i.e. whoever control the e-mail of account X, is account X, no matter what).
    – Margaret Bloom
    Commented Sep 30 at 10:27
  • Email addresses can be recycled, i.e. ones that became inactive are allocated to new users. This is generally though to be bad practice - but some providers do it anyway.
    – paj28
    Commented Sep 30 at 12:52
  • @paj28 Right, but in that case access to the email should indeed grant access to the application. It's the same as if it was email + password, no?
    – Shoe
    Commented Sep 30 at 13:54
  • 1
    I think so. You probably saw a blog like this and it says further down that it's not a problem with major IdPs.
    – paj28
    Commented Sep 30 at 20:28

1 Answer 1

Reset to default
2

for example if a user logs in with Google and then after a few months, not remembering which SSO provider it used, it logs in with Facebook, with the same email, then a new account will be created;

Let's say I want to create an account on tiptopwhistleblowing.com. I decide I trust Google and therefore, I create my account on tiptopwhistleblowing.com using Google login.

If tiptopwhistleblowing.com only uses the email address to identify accounts, someone might try to:

  1. attempt to register a Facebook account with my email address;
  2. or take over my old Facebook account I created 10 years ago (and completely forgot about);
  3. hack into my Facebook account because I never care to actually use a strong password for this service.

and he would be able to access my data ontiptopwhistleblowing.com.

As a end user, I decided I would trust (for example) Google to manage this account (possibly based on some trade-of between usability, privacy, etc.). This does not mean I am trusting Facebook, Apple or Microsoft for that. I may not even have an account on these services.

Let's assume that tiptopwhistleblowing.com includes a method to login through a social network hosted under the jurisdiction of a foreign country. If I have been known to be a critic of this country's government, this social network could be coerced into granting the authorities access to my account on tiptopwhistleblowing.com.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .