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.
Related
I am in the process of adding social media oauth login and registration to an existing site. I've followed the overall process described here:
https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview
Currently, if a user wishes to change their account profile (including email address, password, etc.) then they need to supply their existing password. This is to prevent cookie stealing style attacks, or damage caused by people leaving accounts logged in on public machines.
However, if a user has registered using Facebook then a randomised password is set behind the scenes and the user is not aware that a password exists in our system.
This could make the simple process of updating the user profile a confusing and off-putting task. How do we present the password to the user, and how do we explain that it's different to the Facebook password?
I would like to present a Facebook pop-up or interstitial to the user before they change their account details, to force them to re-authenticate using their Facebook password, but I can't immediately see a way of supplying multiple callback URLs, or passing form data.
Is there a feature or workaround that would let me achieve this?
Please let me know if including any code would help, but you can assume that I'm using a standard Rails app running Devise and the Facebook oauth strategy, with code snippets described in the link above.
Does anybody know what will happen to my existing users when I will change Facebook app ID in allauth (socialauth) configuration?
Will "login with FB" try to create new django accounts or will it just log users in to existing ones (and obviously, asking via FB for permission)?
I'm in a situation where I have large amount of users signed up using FB but now I'm forced to create new FB app and switching to it.
Have checked it out. The answer is yes, users will fall into the signup flow instead of being logged in.
It's because Facebook assigns app-scoped ID to users. An app doesn't know user's original ID, it gets user's ID generated especially for this app. For this reason django-allauth won't recognize existing FB users (from previous FB app).
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 have a website with it's own login/registration mechanism (PHP, session, user and user_profile DB tables with username and password, etc). Let's call this the ABC account.
I just finished integrating Twitter's sign-on using Oauth, available as a "sign-on using twitter" button above my normal login form.
So now I have this scenario:
A user logs on via Twitter. Because Twitter, unlike Facebook, does not proivde access to a user's email address, I don't know if this person who logged in via Twitter is an existing user (in my user table) or not. So I create a new account for them (let's call this the "Twitter" account) and prompt them to merge with an existing "ABC" account by entering their "ABC" credentials. If they do so and everything matches, I store their twitter username, id and token in the DB record for their ABC account. Next time they login via Twitter I know who they are in terms of the ABC account (ie, the accounts are "merged") and all is good!
Except, I'd like to have the ability to have my site send tweets on their behalf, which basically means I need an authorized Twitter connection, which I only have if they logon via the Twitter button, not through the ABC account. The reason is with the latter I have their token_secret, received from the Twitter API callback after signing, but with the former I don't. My first thought of course was to save the token_secret in my DB (with the ABC account record) to remove this restriction, however it seems like this is the equivalent of a password and storing it could be secruity hole?
To boil this down to a question: is it "standard" practice to store the oauth token secret in the DB to achieve what I'm trying to do (which itself seems like a pretty standard function for a modern site)? . If not, what's an alternative implementation?
Update: looking at: Best practices - store Twitter credentials or not? it seems this is definitely not a 'best practice'. But it seems like what I'm trying to accomplish is...not sure how to implement? Maybe some kind of cookie-based solution??
Peter
ps -- BTW, if anyone has a better way to do the account "merge" I described I'd be open hearing about that as well. I did some google searching but really couldn't find anything too useful, although this problem must have been solved many times I imagine??? My understanding is that in the Facebook case the email can be used to "uniqely" identify a user (ie, match them to an ABC account), and do the merge without prompting (although I'm not even sure this is totally secure?).
Storing the tokens that Twitter gives you during the OAuth process is -exactly- how you should be doing it. Shove them in the DB.
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.