6

When one account per email address is enabled for Firebase Authentication in a Firebase project there seems to be some additional rules that apply to the authentication process. The different providers seem to be split into two categories, trusted and untrusted providers. If at any point a user signs in through a trusted provider all untrusted providers the user has signed in with before are removed from the account. Additionally a user will never be allowed to sign in with an untrusted provider ever again. Whether a provider is trusted or untrusted seems depend on whether a new account created with a provider validates that account exclusively through sending a verification email to the address the new account was created with.

I cannot seem to find a comprehensive list as to which providers are trusted and untrusted. Through implementing the solutions into my app I have found the following:

TRUSTED PROVIDERS:

  • Apple
  • Google
  • Microsoft (If the email the account was created with is a @outlook.com or @hotmail.com)

UNTRUSTED PROVIDERS:

  • Facebook
  • Microsoft (If the email the account was created with is not a @outlook.com or @hotmail.com)

Is this understanding correct? Where can I find a breakdown of the rest of the providers? My app is built in Unity so I would be limited only to the providers Firebase supports in Unity. Why is Microsoft both a trusted and untrusted provider in different circumstances? I could really use some help here.

My app is for iOS and Android. I wanted to exclusively use Apple and Google sign in but Apple sign in is unavailable to users on iOS < 13. These iOS devices seem to represent about a 6th of all devices in western nations. I tried to implement Google and Microsoft sign in to get good coverage of these users but then I ran into the complication with Microsoft sign in being both trusted and untrusted. I don't want to over complicate my app with manual account merging, but I don't know what other providers are wholly trusted. What is the best solution here to keep things simple stupid?

Phedg1
  • 1,888
  • 3
  • 18
  • 35

1 Answers1

8

Trusted providers:

  • Google (provided it was issued by Google, eg. @gmail.com)
  • Yahoo (provided it was issued by Yahoo, eg. @yahoo.com)
  • Microsoft (provided it was issued by Microsoft, eg. @outlook.com)
  • Apple (always verified. Apple's selling point is that accounts are verified and multi-factor authenticated).
  • Email link authentication.

Untrusted providers use emails that were not issued by the provider:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo, Microsoft, etc provided they were not issued by that IdP.
  • Email / Password without email verification

Firebase Auth plays it safe and does not consider certain providers verified, because in some cases, email is verified once but is not continuously verified (in some cases, IdPs allow you to change the email after verification without requiring re-verification).

The best way to explain the sensitivity of an unverified account is the following: 1. Attacker signs up with unverified provider (password) using email victim@example.com which they do not own 2. Email owner signs up with victim@example.com using verified provider Google.

If the account is not reset and the password unlinked, then the attacker maintains access to that account which they do not own. To solve this issue, the user has to verify the email (by sending email verification) before step 2. By doing so, sign in with Google will automatically merge accounts and keep the password.

This is why in some cases, you will get an error:

  1. Sign up with unverified provider using email user@example.com
  2. sign in with another unverified provider of the same email
  3. Error thrown requiring linking after verifying ownership of first account.
  4. User expected to sign in to account from step 1.
  5. User can now link credential of account from step 2.

Here is a summary of the behavior in various cases:

  1. existing unverified provider, sign in with another unverified provider of same email -> error requiring linking thrown. (eg. Facebook followed by GitHub)
  2. existing verified provider, sign in with another unverified provider of same email -> error requiring linking thrown. (eg. Google followed by Facebook)
  3. existing unverified provider, sign in with verified provider of same email -> verified provider overwrites unverified provider. (eg. Facebook followed by Google)
  4. existing verified provider, sign in with another verified provider of same email -> Both providers linked without any error. (eg. Apple followed by Google)

If you do not agree with Firebase Auth and want to consider Facebook as a verified provider, you can always set the email as verified after Facebook sign-in by using the Admin SDK.

Hopefully this helps clarify this behavior.

bojeil
  • 29,642
  • 4
  • 69
  • 76
  • When you write "error requiring linking thrown, is it `FirebaseAuthUserCollisionException`? According to documentation, it is supposed to be thrown every time when user tries to sign in with second Bprovider (linked to a@b.com) when there is already account created with Aprovider (linked to a@b.com). But in reality, i see that this documentation is misleading, because Google and Apple sign-ins with same email address (when email addresses are shared) merge silently instead of throwing `FirebaseAuthUserCollisionException`. – Jemshit Jul 24 '20 at 10:45
  • So does this mean, trusted providers are merged into single account when they share same email address, but if one is untrusted provider, then it throws `FirebaseAuthUserCollisionException`? – Jemshit Jul 24 '20 at 10:45
  • 1
    Thread on github: https://github.com/firebase/firebase-ios-sdk/issues/5344#issuecomment-618518918 – Jemshit Jul 26 '20 at 17:56
  • Hey bojeil, nice summary, thanks. But what about 5th case, where I'm trying to log in, for the first time, with unverified provider? for example, I created a user (using admin SDK) and than the user tries to login using Microsoft? (where domain is not @hotmail) – Shahar Glazner Aug 03 '21 at 17:30