1

I'm currently developing a starter kit for my Firebase + Firestore + React apps.

I've been stuck trying to figure out the best way to handle multiple sign-in methods for each user.

At first, I was attempting to do so, using Firebase Auth with the "one account per email" restriction activated (that's the default).

But after a LOT of failed attempts to achieve my intended behavior, I've decided to give up and switch my Firebase Auth to "allow multiple accounts per email".

My main goal here is:

If I'm offering my users 3 sign-up-and-in methods (for example: email/password + Google + Facebook), I feel that I should honor those 3 methods regardless the order that they might have been used.

The fact it that with the "one account per email" restriction that is just not possible, because if your user first signs-up with email/password, Firebase will delete his password if he signs-up with Google the next time. And it will do that so silently that your user will never know why his password is not working anymore (at least that's what I understood from my research and a question to Firebase support).

This is for security reasons, since Google Provider has a higher precedence over other providers (basically because the Google email comes back implicitly verified, in this case). I get that, but I just think that it would make a terrible user experience if you delete a user's password without letting him know that it happened.

I have another question that goes deeper into this issue

But with this question here I would like to know the following:

While allowing multiple accounts per user, I'll have to save my users' data on Firestore using their email as their uniqueID, because using multiple accounts/sign-in-methods per email, each account will end up having a different uid generated by the Firebase Auth system, but they all should have access to the same account on my app, hence I'll have to use their email as the uniqueID).

Note: From my app's point of view: every account on Firebase Auth using the same email address corresponds to the same user.

For example:

  1. myUser@gmail.com signs-up using email-password (send link to verify his email)

  2. Firebase Auth creates one account for myUser@gmail.com/email-password. uid = x

  3. myUser@gmail.com signs-up using Google Sign In

  4. Firebase auth creates another account for myUser@gmail.com/google-sign-in. uid = y

  5. myUser@gmail.com signs-up using Facebook Sign In

  6. Firebase auth creates another account for myUser@gmail.com/facebook-sign-in. uid = z

Since every account will have a different uid, I'll let them all have access to the same data on Firestore using their email as uniqueID, which will be the same for each account, in this case.

QUESTION

Although that seems to solve my problem, I'm worried about possible complications that might bring in the future. Any one of you, more experienced Firebase developers, might think of a reason why I shouldn't solve the problem using the approach explained above?

Keeping in mind that from my app's point of view: "the user IS the email" and not the account on Firebase Auth. Each user might have 1, 2 or 3 accounts on Firebase Auth.

Do you see potential issues/conflicts with:

  • Firestore security rules ?
  • Cloud functions for Firebase ?
  • Some firebase-admin case ?
  • Some kind of messaging system conflict?
  • I don't know... I'm brainstorming here.

Thanks for the help.

cbdeveloper
  • 27,898
  • 37
  • 155
  • 336
  • How are you planning on getting the email address? If you "allow multiple accounts per email" then the provider will not return the email address. – Gilberg Apr 18 '19 at 15:06
  • Get them under here: `userCredential.user.providerData[0].email` look for the `prodiverData` array in the response. – cbdeveloper Apr 18 '19 at 15:16
  • did you already try this. Once I switched to "allow multiple accounts per email" I stopped get the email in provider data (google sign in). I had to add a new scope with the sign in request. The others providers don't give the email addresses either (yahoo, twitter) – Gilberg Apr 18 '19 at 17:35
  • I did not go much further into this. The only provider that I've used was Google and I could get the user details using the `providerData` property. I've heard that if you force the user to verify his email, then a later Google Sign-In won't erase his `email/password` account created before. Since my problem was the silent deletion of the first account created with `email/password`, I might do that (ensure email verify) and go back to the "1 account per email". – cbdeveloper Apr 18 '19 at 17:48
  • Ok, I was able to get the email from twitter by editing my twitter app to request access to the user's email. But I still can't figure out how to get it from yahoo (it is not in the provider data) – Gilberg Apr 18 '19 at 17:49
  • That's tricky. But my bet is that there is a way. Would be really strange if there weren't. – cbdeveloper Apr 18 '19 at 17:52

1 Answers1

1

I don't see any issue with the setup you're describing - and besides, since their email is the only piece of shared identity information you have - it's not like you have much choice. As long as you structure everything based around email address... skipping anything related to the firebase-generated UID, then it should be fine.

One warning I'll give you is that you should pay careful attention to stripping out some special characters from email addresses when you write it in the database. These database docs include information regarding inpermissible characters in a Firebase database key:

If you create your own keys, they must be UTF-8 encoded, can be a maximum of 768 bytes, and cannot contain ., $, #, [, ], /, or ASCII control characters 0-31 or 127. You cannot use ASCII control characters in the values themselves, either.

Many of which are valid portions of an email address.

That's the one big cautionary item that I can think of, otherwise you ought to be good-to-go. Disclaimer that I don't have a lot of experience with FCM, so there might be another consideration I havne't noticed, if you're looking to add a mobile client at some point down the road.

JeremyW
  • 5,157
  • 6
  • 29
  • 30