0

Assume my solution offers 5 identity providers that users can choose from

Apple
Facebook
Github
Google
Microsoft

These providers all take user identity very seriously. Is there any legitimate liability concern that an unauthorized person might be able to authenticate themselves with the same email but with a different identity provider?

The logged in user would have access to their own sensitive personal information and some small funds (worth < $100).

I assume that if that happens, that user's email account must have been compromised, so we can't be liable for that. If one of the auth provider companies was compromised without disclosing it, or allowed people to commit unauthenticated identity fraud, it would be recklessness on their part - and we could help the user recover damages that way.

I'm thinking that the most user friendly approach would be to allow a user to disable "untrusted" auth providers (e.g. a user doesn't trust microsoft, so they can choose to disable microsoft and github sso access), and maybe notify them when their account has been accessed from a new auth provider (although that would go to the compromised email anyways, so is there really a point to that?)

Is there something I'm missing or would that represent sound and reasonable security practice?

related, but doesn't have a concrete answer: Is it safe to rely on email address from 3rd party identity provider?

Improve this question

2 Answers 2

Reset to default
1

It does not work the way you think. For your system, [email protected] authenticating via GitHub and [email protected] authenticating via Microsoft are separate entities.

The user don't need to say "I don't trust Microsoft, so use only GitHub" because they are separate accounts from the point of view of your system. Even if the same user is the owner of both accounts (an attacker cannot create a GitHub account for [email protected] without controlling [email protected] address), they aren't the same for your service.

If anyone registers using Microsoft, and later registers again using GitHub with the same email, there will be two separate accounts.

Improve this answer
3
  • How do you know how my service works? 🤔 The question isn't whether it's possible, it's whether it shouldn't be done. (UIDs are different across providers, but identifiers are the same, so coalescing isn't really a technical challenge)
    – user65023
    Jan 18 at 14:13
  • 1
    If you use standard libraries for that, it's how it works. If you are reinventing everything from scratch, good luck...
    – ThoriumBR
    Jan 18 at 15:06
  • never change, stackexchange :)
    – user65023
    Jan 18 at 15:17
1

One cannot assume that the same email reflects exactly the same identity over multiple identity providers. For example it is possible that someone got temporary access to a users email (attack or temporarily unobserved device) and was thus able to create an account with a different identity provider - while the real owner of the email has no knowledge of the account and no access to it.

By designing your application to accept any of these identity providers no matter which one was used with the previous login you basically burden the user with creating accounts with all of these identity providers in order to prevent others from doing so.

Improve this answer
4
  • We're talking about a scenario where B registers with A's email, throws A's email out, so that A can't recover the account, but the SSO identity will still display A's identifier even though it's now linked to B's identity? I don't know if that's true: google for example notes that while the UID will stay the same, the identifier may change. So in this example where B has attempted to poison A's identity in this manner, B won't be able to access A's data with the fraudulent account. ex: github.com/flutter/plugins/blob/main/packages/google_sign_in/…
    – user65023
    Jan 18 at 15:35
  • @user65023: "throws A's email out, so that A can't recover the account" - nothing like that. The email stays there. A simply has no idea that an account with their mail exists with this identity provider so A would not even attempt to recover it.
    – Steffen Ullrich
    Jan 18 at 16:20
  • in that simpler case, notifying the user via email that this happened should probably suffice. It's akin to logging in from a different device - notify, and allow the user to take action if necessary?
    – user65023
    Jan 18 at 20:12
  • @user65023: For the initial registration the attacker has access to the device and can delete any mails notifying the user. As for later - it looks like you make assumptions of how the identity providers will work without any kind of guarantee that they will actually do this in the future (or even now). Your design idea is operating out of the scenario how these identity providers are meant to be used and thus outside of their security evaluations.
    – Steffen Ullrich
    Jan 18 at 21:20

You must log in to answer this question.

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