I’m using Facebook to authenticate users. We also have conventional username/ password login and registration form too. Anyway, when a user chooses to login with Facebook, we use the following procedure:
- Redirect to Facebook, user is authenticated, returneded from Facebook to the app – email, name, facebook ID etc is provided from FB .. but ofcourse, no password
- We look in our system for any existing user by the email address. If a user is found, then that is the currently logged in user; otherwise, create a new user with the user info returned from FB.
Email kinda makes sense as we don’t want duplicate email addresses (also the database currently won’t allow it due to unique index) so if a user has signed up already with that email address, it won’t attempt to create a new user for them. Instead it will pull the previously registered user.
Is this the sound approach though? Exploring all possibilities, I was wondering what happens in the event that the user tries to register by our conventional registration form, but as they have already created an account with that email from their initial Facebook login, we wouldn’t allow the duplicate email. So having made the decision to use their Facebook to login, they are stuck with that method. Is this a common/ok approach?
Also without intention, if they use the conventional registration form first, and setup their account that way, we have their password, so they could login using our form or login with FB and the user account will just be pulled by email. However, if they choose to login with FB first time, and their account is created that way (we won’t obtain the pw), they must always use FB only. I’ve absolutely no idea whether this could be problematic or not, I kinda want to go with the option of – whatever means you chose to login/register first time round – then that’s what you stick with 🙂
I’m a little new to having users sign up with multiple logins so heads a bit full of “what ifs” etc. Would appreciate any advise on this, and common approaches. Thanks
Alternatively, we loose the index on the email field, add a field somewhere to store the facebook ID, and at the application level decide whether to permit duplicate email address and more distinction between users of different login methods (therefor allowing a user to have a conventionally registered user account, and/or a seperate facebook login auth/created user account, both with the same email address – but different methods of login – least if the user deletes their Facebook account, they can create an account with their email through our register form)
I separate Users/Profiles from Authentication on my apps. This might be an approach you can use. Especially if in the future you think you might add twitter or other authentication providers to your system.
Basically I create a table called Credentials that stores the unique UserID in my system and the Unique id the provider gives. Email is not good because the user might change their email with the provider. Facebook provides a unique ID for each user in their token.
When a user authenticates, I look for the matching provider ID in the credentials table. (Don’t forget to record which provider because otherwise you might find a match for a twitter login when the user logged in with facebook). Finally, I grab the matching User in my system who has the same UserId as the credential record.
There aren’t that many steps in reality I was just spelling it out. In truth I just need one query
select U.* from Users u
inner join Credentials on
u.userId=Credentials.userId
where Credentials.ProviderId =?
and Credentials.Provider=?
System stored username and password of course would look different. But you already know how to handle that.
Regarding requiring a separate login even when the user comes through facebook. Please do not do that…that is the most irritating thing to me as a user when I’m given the option to login through facebook and the system still requires me to create a password. I’ve left sites in the middle of registering for that very reason.
3
Some sites (e.g.: Asana) employ the same tactic as you do: If you register using a 3rd party and then try registering again using their own login, you will be politely reminded that you are already registered and redirected to the 3rd party login. If you go about it the other way around, you will still be able to log in using your own password.
Other sites (e.g. Wunderlist) will make you create a password even if you register using a 3rd party.
So both approaches exist out there. Which one you use is up to you.
The first approach makes registering more straightforward. The login experience may be different for different users, but it is just as simple for all of them.
The second approach gives your users a uniform experience at login. It also gives them a choice of login, in case they get paranoid about Facebook.