FirebaseAuth should consider Facebook emails as verified.

[janniklind]

[REQUIRED] Step 1: Describe your environment

• Xcode version: Version 11.3.1 (11C504)
• Firebase SDK version: 6.21.0
• Firebase Component: Auth
• Component version: 6.21.0
• Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem

Firebase auth is not following Facebook's guidelines regarding Facebook sign in and merging of accounts: https://developers.facebook.com/docs/facebook-login/multiple-providers#associating2

After a successful login using Facebook, you will have the person's email address, Facebook ID, and access token. Your app should search for an existing account that has been created with that same email address. If one exists, you should merge the two accounts and add the Facebook info to the existing account

How to reproduce:

1. Setup Firebase authentication for the providers: Google and Facebook.
2. Sign in the user using Google.
3. Log out.
4. Sign in the user using Facebook

Expected behaviour: Given the Facebook user has an email associated with his Facebook account, the sign in should complete without any additional prompts.
As stated in the Guidelines from Facebook: https://developers.facebook.com/docs/facebook-login/multiple-providers#associating2

Current behaviour: Firebase auth throws an error "ERROR_ACCOUNT_EXISTS_WITH_DIFFERENT_CREDENTIAL", and then we need to fetch providers for the existing user using fetchSignInMethodsForEmail, then the user should sign in using Google, and only after that we can link the accounts and the user can from now on use Facebook without this annoying prompt.

Additional information:

If you run the scenario using Apple Sign In instead of Facebook sign in, it works perfectly, because somehow Google trust the email is verified by Apple, but Google don't trust Facebook.

Please fix this issue, it has been hanging for years and both developers and users is really annoyed by it. - and I think more developers tend to not using Firebase Authentication before of this thing.

If Google don't want to take the responsibility of trusting Facebook, then let it be up to the developer to decide that by flipping a flag in the Firebase Console.

[morganchen12]

@bojeil-google what's the reason we don't do this?

[bojeil-google]

Hey @janniklind you have been spamming multiple Firebase repos with this issue. I have seen at least 10 posts from you on this same topic.
This is works as intended. If you do not agree with this behavior please file an official support ticket on this.

[morganchen12]

Thanks @bojeil-google. Closing this since it's a duplicate.

[janniklind]

@bojeil-google Yes I have made comments on some of the many threads where people are facing this same issue (for years), but where you continue to close the issues without any explanation.

The same way you close this issue as a duplicate, but not really mentioning that the others are already closed or could be considered as closed as well, because you clearly state everywhere that this is intended behaviour.

I am questioning, why is this intended behaviour then? I mean your arguments about the Facebook email not being verified, is clearly not what Facebook states in their documentation. And even if Facebook guarantees that they verify the emails, you don't trust them because they are not the owner of the email domains. At the same time you consider the emails from Apple Sign In as verified, even though Apple neither owns the email domains.

I just think the users of Firebase Auth with Facebook wants to know the technical or political reasons for why the emails are not being considered as verified.

[stoppiNeobiz]

hi @janniklind I've the same problem, do you have resolve?

[MeghaB]

Hey @janniklind,

Megha (Firebase engineer) here -

I understand your frustration - and hope I can help provide some more context.

We consider the email verified if it's:

• verified via our verification flow (in Email/Password login plus email verification)
  or
• verified by the domain owner (ie: Yahoo - @yahoo.com accounts, Microsoft- @hotmail.com accounts, Google - @gmail.com accounts, etc)

Let me provide some example scenarios to help highlight why the behavior you noted is WAI:

Case 1: Annie creates a FirebaseAuth user, logging in for the first time using Google via an @gmail.com account (or other Google-managed domain).
Bob comes in later, and attempts to sign-in using that @gmail.com account via Facebook.
As you correctly identified in your previous comments, Facebook doesn't own the @gmail.com domain, and so we’re unable to provide any guarantees that it’s verified. In this situation, we wouldn't want to erroneously link these two accounts, giving Bob access to Annie's account.

Facebook’s documentation notes that when linking accounts, the developer should ensure that the email address passed in for Facebook login is valid when linking accounts (“If you use an email address as the unique credential which identifies each account, your app should verify that the email address associated with the person's Facebook account (and obtained during Facebook Login) is valid. You can do this by creating code in your app to send a verification email to the address obtained after Facebook Login (you will probably need to have this step as part of your regular login system anyway”).

Case 1a: Annie is attempting to login the second time via Facebook with her @gmail.com address. Here, we’d recommend ‘linking’ the two logins - FirebaseUI handles this for you (Firebase UI) or you can handle it manually via the core sdk, responding to the ‘ERROR_ACCOUNT_EXISTS_WITH_DIFFERENT_CREDENTIAL’ response.

You mentioned that Case 1’s behavior was different than in the case of Sign in with Apple, but the situation is not actually the same:

Case 2: Alice is logging in with Google (gmail) and then Sign in with Apple (using her Apple ID, which happens to be her @gmail.com address).
There are a few subtleties here which is perhaps adding to the confusion, so I want to highlight them:

A. As Apple is an IDP (not a social login), it provides additional guarantees around all emails being properly verified (Sign In With Apple), and so is a verified provider.

B. In the case of Sign in with Apple, Alice is providing an Apple ID - Apple allows users to hide their email address from you (via a privaterelay.appleid.com email address that will forward to the user’s real email address).

Both Alice’s logins are via verified providers (gmail with Google, Apple ID with Apple), and we’ll automatically link these two accounts, if Annie elects to share her real @gmail.com email address instead of her relay address. If she uses a relay address, she will have created a new Firebase Auth User or link that relay to her Google-based Firebase Auth User.

As Apple is a fully-fledged iDP, it provides the necessary guarantees around email verification (https://developer.apple.com/sign-in-with-apple/) - in order for the Apple ID login and the Google login to be successful, the user must be Alice (who has access to both her @gmail.com account and her Apple ID credentials).

In summary:

• If both login attempts are successful and via verified providers, we automatically link the accounts if we’re able to recognize the match.
• If the first login was via a verified provider, but the following was not - we will return ‘ERROR_ACCOUNT_EXISTS_WITH_DIFFERENT_CREDENTIAL’
• If the first login is unverified (ex: using Email/Password, but without the email verification enabled or complete), and the second login is successful with a verified provider, we ‘elevate’ the verified provider, and unlink the previously unverified login, to similarly prevent malicious users from gaining access to someone else’s account. This behavior is to prevent Bob from ‘camping’ on Annie’s account (using her email address illegitimately), wait for Annie to legitimately login via Google, and then silently have access to her account through an account linkage.