I have recently implemented login to my via facebook connect. So now users have 2 ways of logging in to the site. The old way of registering an account and the new way (facebook connect).
One thing I would like to do is link a new facebook connect user account to existing accounts if they logged in the old way.
Has anyone had any success doing this?
Very good question I think and lots of people will benefit from an answer.
What you need to remember is that accounts are only linked so long as they are authorised to be linked through Facebook. What you should do is maintain a second table of linked accounts in your database so that you know who is who and if they are linked with Facebook.
You should read this integration comment, it provides a lot of useful information.
http://crazyviraj.blogspot.com/2010/01/test-cases-for-basic-facebook-connect.html
It doesn't really say how to do things, but it makes sure you tick all the boxes of what you should be doing.
ie:
Sign Up should fail if the user denies
permission to the app (category: sign
up)
Since we need access to an email
address, Sign Up should fail if the
user provides publish permission but
denies email permission (category:
sign up)
If the user provides an email address
that already exists in your system,
fail Sign Up. Make sure no YouFace
backend tables are modified (category:
sign up, 1:1 mapping) PS - when this
happens, I didn't find a way for you
to de-authorize YouFace on the
Facebook user's behalf. The user must
manually do this if they wish you use
the same account but provide a
different email address.
Accounts created using Facebook
Connect should not be able to login
using YouFace's default email/password
login system (category: sign in,
account security). PS: Since YouFace
accounts require a password and those
created using Facebook Connect don't,
make sure to insert a random password
hash into your table to avoid silly
errors
Accounts created using YouFace should
be able to sign in without requiring
to be signed into Facebook, even if
when a link to a Facebook accounts
exists (category: sign in)
Any many more
You should be asking for permanent access through fb connect authentication. Once you've done that, you'll get a token which gives your permission to access someone's Facebook information, and that token will not expire unless the user explicitly removes you from the permission list or changes his/her password.
Once you have the token, associate that token with the user / create a new field in your user table to store it.
To associate the user with a Facebook account without the user logging in, you can try to match by email. It's not 100% accurate but it's pretty good. Facebook doesn't give you email addresses in text form but you can get email hashes from FQL. Since you already know user email addresses, you can calculate the hash for all of your user emails and search through your user base for matches every time a new Facebook Connect user signs up.
Related
At the first time, while signup with Gmail and password, firebase saved the credentials correctly. But the next time, I Login with Firebase Google authentication with the same Gmail which i gave while signup, the credentials are overriding in firebase account. After overriding the credentials, we are not able to login using that signup credentials. Can anyone explain how to achieve this?
What happened
In the first screenshot you signed in with the email+password provider of Firebase. While this is a valid sign-in method, it means that anyone could've entered that email address, even if they don't actually have access to the Google account for that gmail address.
There is no security risk here, but the level of trust we can put in the value of email address is low. For this reason the emailVerified property of the account is marked as false and you'll typically want to require that the user verify their email address before allowing them to continue.
In the second screenshot, the user signed in with the same email address, but now with the google.com provider of Firebase. This means that Google now verified already that the user has access to the underlying gmail address of the account. Since the google.com provider is the trusted provider for #gmail.com accounts, the system replaces the previous account.
Also see:
Authentication using Facebook at first and then Google causes an error in Firebase for Android
Firebase Overwrites Signin with Google Account
Trying to understand Firebase Authentication one account per email address and trusted providers
What you can do
You'll typically want to prevent multiple users from signing up with the same email address. For this, you'll want to configure Firebase to only allow a single account per email address in the console, and then use account linking so that the two (email+password and google.com) accounts in your scenario are merged.
Did you verify the email or phone number from the first login attempt? If not, this is by design:
After sign-in completion, any previous unverified mechanism of sign-in will be removed from the user and any existing sessions will be invalidated. For example, if someone previously created an unverified account with the same email and password, the user’s password will be removed to prevent the impersonator who claimed ownership and created that unverified account from signing in again with the unverified email and password.
Source
I just ran into this problem and here is a longer and more in depth description. (Things change often, this was true in Nov 2021.)
SHORT VERSION: As #Frank van Puffelen said, this is by design. The issue is that email+password is not a trusted provider usually, so a trusted provider like Google Authentication overwrites that method. It does this silently (I think, didn't check every field in GoogleSignInAuthentication object.)
It does auto-link after a password reset OR the email is verified via a link. See https://firebase.flutter.dev/docs/auth/usage/#verifying-a-users-email on code to do that.
Also: I don't recommend turning off One account per email address as some others suggests . See the reason for that at the end.
"Weird" Behavior under default One account per email address
In my app, the following happens.
SignUp via email+password for testUser1234#gmail.com.
creates an account for c_example_account#gmail.com with provider=Email/Password as indicated by the envelope/mail icon in the firebaseAuth dashboard.
LogOut and re-signin via Google Sign In for c_example_account#gmail.com
The provider is changed. Old provider is Email/Password icon (envelope). New provider is Google icon. (like the bottom three accounts in the screenshot). Note also that the User UID is the same. So anything anything linked to that User UID is still okay.
Since the Email/Password login method (AKA) provider was removed for c_example_account#gmail.com, the user can't login with that method anymore. IMPORTANTLY: This is done silently without the user getting any notification that the Email/Password login was removed.
Trying to sign on using Email/Password will result in an error Incorrect Password. Note: one might expect it to give an error like "Only Google Sign-In is available", but it doesn't. Contrast this to when the email doesn't exist (like trying garbage#123457.com), which has an error Email is not found...
Now, it gets a little weirder...
Suppose the user uses "Reset Password" like being called like this
Future<void> resetPassword(String email) async {
await _firebaseAuth.sendPasswordResetEmail(email: email);
}
Then, the firebaseAuth console has TWO methods for the same USER UID. See the second and third line in the screenshot.
Now, both methods are allowed. The difference is that the first time was a createUserWithEmailAndPassword() like
await _firebaseAuth.createUserWithEmailAndPassword(
email: email,
password: password,
);
...but this time it was created via a "Reset" event
Future<void> resetPassword(String email) async {
await _firebaseAuth.sendPasswordResetEmail(email: email);
}
... that gave a link via email sent by firebaseAuth service. In this case, the email was verified.
Recap: Now both methods work. The two methods being (1) Google authentication and (2) Email/Password. In Google parlance, the accounts have been linked: https://firebase.google.com/docs/auth/android/account-linking. Linking means One User UID, multiple login methods
Why the funky behavior when Email/Password is created in two different methods?
~~I couldn't find this documented in firebaseAuth, maybe because I didn't look hard enough or maybe because it's not a common issue. ~~
UPDATE: This behavior is documented in an issue comment from April 2020.
I think the reason is because the _firebaseAuth.createUserWithEmailAndPassword version has an unverified email. So, anyone can create an account for anyone else assuming that the email+password combination doesn't exist. For example, I could create an account with username president#whitehouse.gov without actually having access to that email. If the actual president logged in via Google Authentication, then I'd have bogus access to that user's info. Except that the clever google engineers decided that the verified Google Authentication then triggers the deletion of the unverified Email/Password provider/account instance.
In short, the logic might be: verified trumps/overrides unverified. See https://firebase.google.com/docs/auth/users#verified_email_addresses
Again, none of this is documented explicitly for Email/Password. But it is hinted at in the documentation, like if a Facebook Auth account gets over-written by a Google Auth.
Snapshot of the Verified Email details
Copied from: https://firebase.google.com/docs/auth/users#verified_email_addresses
Bolded added by me, for emphasis
In some situations, Firebase will automatically link accounts when a
user signs in with different providers using the same email address.
This can only happen when specific criteria are met, however. To
understand why, consider the following situation: a user signs in
using Google with a #gmail.com account and a malicious actor creates
an account using the same #gmail.com address, but signing in via
Facebook. If these two accounts were automatically linked, the
malicious actor would gain access to the user's account.
The following cases describe when we automatically link accounts and
when we throw an error requiring user or developer action:
User signs in with an untrusted provider, then signs in with another untrusted provider with the same email (for example, Facebook followed
by GitHub). This throws an error requiring account linking.
User signs in with a trusted provider, then signs in with untrusted provider with the same email (for example, Google followed by
Facebook). This throws an error requiring account linking.
User signs in with an untrusted provider, then signs in with a trusted provider with the same email (for example, Facebook followed
by Google). The trusted provider overwrites the untrusted provider.
If the user attempts to sign in again with Facebook, it will cause an
error requiring account linking.
User signs in with a trusted provider, then signs in with a different trusted provider with the same email (for example, Apple
followed by Google). Both providers will be linked without errors.
You can manually set an email as verified by using the Admin SDK, but
we recommend only doing this if you know the user really does own the
email.
Why not turn off One account per email address
By default, the setting One account per email address is active as #Deva wrote. But, unchecking this means that there are two different accounts (User UIDs) for the same email. One via Email/Password and one via Google Authentication. They will have separate User UIDs in Firebase Auth, so that may confuse you. Furthermore, if you manually link in your app two User UIDs, this creates a security hole: Someone can create an account without email verification to get access to an existing account. So don't do that.
Related StackOverflow questions and links
https://stackoverflow.com/a/60276351/233382
why i can't link email/password to the same email exist in google sign in provider in firebase flutter?
https://github.com/firebase/firebase-ios-sdk/issues/5344#issuecomment-618518918
I have finally managed to implement Facebook as an external login provider on my MVC website which seems to be working fine, but I am wondering what is the correct / secure way to allow multiple external login provides to be linked to a single account.
Lets say I login with my facebook ID, no existing account is found with the same email address and my website persists a new account with their email address and their facebook token etc associated.
Next day I login with my Google account, If i check my database for an account which already has a matching email address what should I do?
1) Link this Google account with the existing account automatically and
log them in?
2) Ask the user if they wish to link their google account to the
already existing account we found?
3) Something else?
Thank You.
It is really up to you. But the default provided in the VS2013 template assumes a one to many relationship between your internal user and any external logins. If you retrieve a user with UserManager, you will see a IList for each external provider the user has logged in with.
As they log in with the new provider, you would normally not automatically know the user is associated with another provider's login. When you login it looks up a user via external ProviderKey, so initally would not find any relation to an internal user. At that point you could search users by name, email (with customized user store) and so on to link as needed.
Assuming primary emails registered on facebook and google for example, are verified by them (which they usually are) I don't see any issues on linking them together.
I think the main problem is linking internal account with email that was not verified to be from specific user. If i create an account with email of other user and that email is not verified, when the other user creates an account it associates the data of the first user together and that way both users are using the same account.
Can anyone identify and explain potential flaws for my first claim please?
I want to give the opportunity for a user of an app to register/login with Facebook or by creating an account. I know that I can get the user's Facebook account email address, and their first and last names. That's basically the only information for creating a 'local' app account, apart from a password. How can I make sure that if that person logs in to Facebook on another device, that their two devices are linked to the same 'local' account? (i.e if they choose to sign in with Facebook with 2 devices, I only want one local account to be created on my server for that user).
Ideally, I want the login schemes for both to be identical. So if that user logs in with Facebook, I can check (securely) that the FB account is linked to a 'local' account, and automatically log that device in without making the user type in a password. Is this possible?
Edit: The 'local' users will be stored in a database on my server, and the front end will be done in Python running alongside the API for the app. Note that 'local' is just referring to the fact that it uses my app web service rather than an external social network.
You can do that within your users database as per below:
assuming you store the user data in a table named userinfo, this table should contain user e-mail, first name, etc..
Add another column in this table named fbemail.
If users signs in using web service, his email will be saved in the email field & the fbemail should be null, if signs in using FB, then both email & fbemail should be the extracted email.
when the user uses FB login, check the fbemail field, if not found, then this is a new user, add his data, if not, then this is a returning user, no need to add his data.
Option 1.
You can identify your Facebook user by his Facebook User ID. If he logs in using Facebook on other device you know it cause he sends you his Facebook User ID in the authentication process. He also sends you Facebook access token which you validate contacting Facebook to see if it is correct. Using this approach you have to have a different authentication scheme for Facebook user and "normal", email user.
Option 2.
To have the same login scheme you can use Facebook to get user email and prepend it in the email text field in your registration screen. The user would need to additionally provide a password. This means that you are not really doing a Login with Facebook, but use Facebook to obtain an email (and any additional information) so the user does not have to type it.
This is an old post but still very valid. You are correct, anybody who has your FB email could potentially access your server rest-api and log into it. To access a backend service you will need to use as password the FB access token generated during the FB log-in. This is stored in the device keychain and can be retrieved as:
NSString *accessToken = [[FBSDKAccessToken currentAccessToken] tokenString];
NSString *userID = [[FBSDKAccessToken currentAccessToken] userID];
The topic of using a FB authentication system in parallel to a custom login/registration system is covered in this FB guide: Using Facebook Login with Existing Login Systems.
In sum, different scenarios need to be addressed:
A person signs up for your app using their email and password, but later they want to use Facebook Login to obtain data from their Facebook account, to post to their timeline, or just to use to log in with in future.
A person signs up for the app using their email and password, but later chooses to log in with Facebook separately. This guide assumes that the email supplied first and the primary email associated with their Facebook account are the same.
A person signs up for the app using Facebook Login and later wants to log in to this account using an email address and password.
The guide recommends using two different tables for the FB log-in and the custom login.
I've been looking into OAuth for a while, but haven't implemented it in any of my applications yet. I'm having trouble really understanding the full concept, so I still have a few questions that I haven't found an answer to, so I hope that anyone can help me.
I want a user to be able to start my application (WP8), login to facebook / twitter / microsoft / ... .
When he gets authenticated, I want to actually save this user to my own DB so I can add some user specific stuff like preferences, posts, ... .
What do I need to save in my own DB to specify a user?
Do I need to save the token itself or is this something that will be invalidated after a while? Or do I need to specify the user's name? With other words: What can I use as a unique identifier?
And what happens when a user would authenticate with for example facebook and he deletes his account?
And one more question, would you ever allow a user to connect to an application with 2 different service providers? If so, how would you make the coupling of these 2 providers to 1 user in your own DB?
I hope my questions are clear enough!
If not, don't hesitate to ask for more information!
Kind regards,
Gert
I assume that you have your own back-end where you authenticate your own users and your WP8 application is just a client.
First, let me distinguish between a user credential and a user profile. User credential is something that validates who the user is, e.g. username/password, facebook user id supplied with a valid auth token. User profile, is what you store in your own database about the user.
You also need to distinguish between a token you use to authenticate the user and the AccessToken Facebook needs to grant you access to user's data.
So... to answer your questions:
What do I need to save in my own DB to specify a user?
Create a record with user data (like preferences, and your unique user ID), and user's login method (e.g. Facebook) and credential (e.g. Facebook's user ID). This is your user's profile.
Do I need to save the token itself or is this something that will be invalidated after a while?
You can also store the Facebook AccessToken here if you've been granted "offline access" privileges by Facebook, but that is used for Facebook's access by you... not by the user's access to your app/back-end. For user's access you could just use a mechanism similar to cookie-based authentication - it's up to you. You could use the AccessToken as a kind of a "cookie", but you would need to always check against Facebook that it's valid.
With other words: What can I use as a unique identifier?
You could treat Facebook's ID as unique (so long as you never allow another account in your user profile DB to link with the same Facebook account)
And what happens when a user would authenticate with for example facebook and he deletes his account?
It's a good idea to have users still create a username/password combination that works with you site and only rely on Facebook login for convenience. In any case, Facebook provides a "Deauthorize Callback URL" when you create an app profile on Facebook. This is called when a user deactivates your app or deletes an account with Facebook. When you receive this call, you could send your user an email when an auth link to setup a different credential so as to not lose access.
would you ever allow a user to connect to an application with 2 different service providers? If so, how would you make the coupling of these 2 providers to 1 user in your own DB?
Sure, you could do that. Say you'd want to allow a Twitter account as well. You'd need to add a Twitter user ID field to your user profile database.
Here's another tip: create an ASP.NET MVC4 project in Visual Studio - the template includes an example of how to set up a user profile database with OAuth login.
Hope it gives you the high-level overview to investigate further.
I am adding Twitter and Facebook login to a MVC 3 test application using TweetSharp and Facebook C# SDK.
Currently when a user signs in using Twitter I create a user account for that user in a user table and store the id, token, and token secret in a separate table with a foreign key to the user table. Since the id, token and token secret do not expire I can quickly locate the right user account when the user logs in next time using Twitter.
What if the very same user logs in using Facebook next time? Since Twitter does not provide email in their API and I therefore have no common piece of information to tie a user account to either Twitter or Facebook I assume I have to create a new user account for a Facebook login? Does anyone have any experience with this? Are there any ways to solve this?
I identify each user internally with a unique key. I check cookies for the user key when any user hits the site. If there's no cookie I create a new key. add it to the user database and set a new cookie. Once a user completes registration the first time by logging in with any of Facebook, Twitter or .Net membership , that key is forever married to that user.
So when an existing Twitter user logs in for the first time with Facebook, we know who they are because their user key exists. It is basically the same solution as macou suggested. Macou's has the plus of working on a new machine or if cookies are cleared, the cookie solution has the plus of not requiring additional user input.
Not really a solution, more of a work around. I was faced with the same problem and ended up forcing the user to complete thier account profile by asking for their email address before allowing them to proceed any further. This meant that if the email address coming back with the Facebook auth matched the email address created with the twitter signin then I didn't need to create another account.
The bigger difficulty was coming the other way, if the account was created by the facebook auth first. It meant an untidy marry up of accounts.
To be honest the information we got from allowing users to sign in with twitter was not worth the effort and in the end finished up only allowing Facebook auths. I'm not sure how important twitter is to your solution.
Not the perfect answer I know, but I thought I would share my experience.
You can't use just a cookie because I can login as facebook then my wife login as twitter using the same browser, you shouldn't link the two accounts in this case.
I think you need to do more than that:
Use a cookie then
Use name/first name/login name/... to see if they match.
Example:
Cookie id: 18459439731114330636, find user with id = 18459439731114330636. Found, go to 2, not found, go to 3.
Is username/first name/last name/... matches the current user? if yes, link accounts. if not, go to 3.
Create a new user.