Multiple logins in Firebase

[Holger Sindbæk]

I have a question regarding having multiple logins (login with Twitter and Facebook). 

I already have authentication with both services. You can only login with Facebook, but after you've done that, you can link you account with Twitter as well. I'm using this post to the the user mapping - http://stackoverflow.com/questions/15148089/how-can-i-login-with-multiple-social-services-with-firebase.

I would like to have the option for my users to be able to login with both Facebook and Twitter to start off with, but I don't know how to get past this scenario:

1. A user logs in with Facebook and I create an account with a UID for that account.

2. A couple of days later the user decides to login with Twitter instead.

How do I log him into the account that was created in the first place, when he logs in with Twitter the second time? How do you deal with this scenario?

[Tom Larkworthy]

The way I have seen games do it, is by offering a user to link accounts. That is, after logging in with one provider, you are given the option of linking by logging into a second. In the link above, after the second login, the user would no longer have write access to their existing record (the auth.id and provider would change). One work around would be to let the user remember a key to unlock the record without a login.

"users": {
    "$userid": {
      // Require the user to be logged in, and make sure their current credentials
      // match at least one of the credentials listed below, unless we're creating
      // a new account from scratch.
      ".write": "auth != null && 
        (data.val() === null || (newData.key === data.unlock && newData.unlock === null) ||
        (auth.provider === 'facebook' && auth.id === data.child('facebook/id').val() || 
        (auth.provider === 'twitter' && auth.id === data.child('twitter/id').val()))"
    }
  }

Now someone can write to the users record, as long as their write includes a key record which matches the unlock record (IMPORTANT: and they remove the unlock record so its one use only)

So the flow then becomes

1. login a new user as normal

2. if the user choses to link account

2a. write a long random unguessable KEY in $userid.unlock, and remember it in the client application

2b. let the user log into a new provider

2c. let the user write a mapping record from the new provider to the existing $userid

2d. update() (or set the whole record) the new provider credential in the $users record  AND set the key to the KEY value AND set the unlock record to null.

For example, something like

var updatePayload = {

   key: <KEY>,

   unlock: null

});

updatePayload[ref.getAuth().provider] = ref.getAuth().id; 

ref.child("users/<myuserid>").update(updatePayload);

*its important the unlock get wiped every time its used, otherwise after an unlock the user record can be updated by anyone, so you want the key to be one use only

Now you can generalize this idea to allowing a user to create two independent user records, then merging them later, by leaving keys in the appropriate places before initiating a merge and updating the various pointers.

 

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/79ae2c88-a8d5-4901-9cd9-c103e23a8811%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Holger Sindbæk]

Thanks for the answer... it wasn't fully what I was looking for though.

If the user logs in with Facebook first and then a couple of days later when he is logged out, he logs in with Twitter. There's no way to detect that he has logged in with Facebook before and automatically link his Facebook account to his Twitter account?! 

[Tom Larkworthy]

You can configure how long the user session is remembered in the Firebase dashboard under login & auth. You could set that to a very high length and the second login would not be a possibility.

There is no real way to know a twitter account is representing the same person as a Facebook account. You could leave some details in local storage to prompt the user to use the same login method each time by default, or warn them they used Facebook login last time or whatever.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b5da4a72-8ffc-4ece-84a9-668da1491517%40googlegroups.com.

[Holger Sindbæk]

Hmmm ok. So it's kind of a best guess scenario. Thanks for the answer.

Are there any security reasons not to set a very high logout timeout?

[Tom Larkworthy]

The main problem vector is with people sharing devices, so thats why some site provide a check box with "remember me" to allow the user to decide the session behavior. 

In Firebase, you can let the session timeout differently per user by setting the "remember" option during auth

https://www.firebase.com/docs/web/guide/login/facebook.html

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d0e03872-8430-4934-abfd-64749691a1e3%40googlegroups.com.

[Nick Halper]

Holger,

I've been tackling something similar for lazy registration, but I think you could apply the same principles to get what you want working, so here is a possible approach:

1) when a user starts your first session, auth them anonymously with infinite timeout so their session will persist. That will be their user id and their user auth token.

2) when the same user logs in via a social account (twitter/fb/etc.), auth them through firebase but hold onto the original anon auth token. To link that social account, write that anon auth token to a directory that only their social login can access. To login via that social account, read the anon auth token from that directory, and once read use customAuth with that token to restore their original anon id.

Nick