I've built an application that requires users to authenticate with one or more social media accounts from either Facebook, Twitter, or LinkedIn.

Edit Once the user has signed in, an 'identity' for them is maintained in the system, to which all content they create is associated. A user can associate one account from each of the supported providers with this identity.

I'm concerned about how to protect potential users from connecting the wrong account to their identity in our application.


There are two main scenarios that could happen:

  • User has multiple accounts on one of the three providers, and is not logged into the one s/he desires.

  • User comes to a public or shared computer, in which the previous user left themselves logged into one of the three providers.

While I haven't encountered many examples of this myself, I'm considering requiring users to password authenticate with Facebook, Twitter, and LinkedIn whenever they are signing into our application.

Is that a reasonable approach, or are there reasons why many other sites and applications don't challenge users to provide a user name and password when authorizing applications to access their social media accounts?

Thanks in advance!


A clarification, I'm not intending to store anyone's user name and password. Rather, when a user clicks the button to sign in, with Facebook as an example, I'm considering showing an "Is this you?" type window.

The idea is that a user would respond to the challenge by either signing into Facebook on the account fetched from the oauth hash, or would sign into the correct account and the oauth callback would run with the new oauth hash data.

  • 2
    What's with all the Edit /Edits? Stack Exchange keeps a comprehensive history of all question edits that's available to everyone: programmers.stackexchange.com/posts/177589/revisions Commented Nov 29, 2012 at 0:35
  • I suppose I just saw a few other questions that do this, and thought that was the norm. Thanks for pointing this out as un-necessary :)
    – BrMcMullin
    Commented Nov 29, 2012 at 18:07

5 Answers 5


Answering the updated question

I would avoid any scheme that requires the user to type their social media password anywhere in your application. It will put many users off even if you put a big explanation next to it that you are not storing this password or using it for anything else than one-time verification. After all, how are they sure they can trust you?

A simple confirmation page should be enough to address your concerns in your first scenario (multiple accounts). Just show it to the user before you start using the social media account as their identity.

The best approach to address your second scenario might be to let the user update their identity. So if they realize they are signed up with someone else's account (they clicked through the confirmation page without looking), they can always go back and update it.

You could also check the OAuth credentials periodically to see if your application still has access to their social media account, and stop using it for identity if not. This will let the third party revoke the access in your second scenario.

Original answer

It seems to me that users can be concerned about your application asking them about the password to their accounts. By now they have been trained to expect the OAuth based authentication for your application.


It defeats the benefits of open authentication if you still require the user to create a new password. The idea of oAuth is that the user manages their password on another network, and they never disclose that password to the website they are logging into. That improves your sign up rates since they trust their social network, but may not know your website very well.

An alternative approach is to use oAuth to assist in user sign up. Rather then use Facebook to log in. You can use Facebook to populate common fields in the user's profile on your website, and then have them sign in without Facebook later.

The problem you are describing is a common concern with oAuth approaches, but it's an issue between the user and Facebook. Since they are using Facebook to sign in, then it's the user's responsibility to sign out on public terminals. If they fail, it's no different then that user walking away with their bank account open on the web page or other important personal information.

  • Thanks for the response! I wasn't intending to ask users to create passwords, but to prove to the provider in question that they do in fact have control over whatever account is returned to the oauth callback. I tried to clarify this in an edit :)
    – BrMcMullin
    Commented Nov 29, 2012 at 0:04
  • Hmm.. interesting idea to show a "is this you" but is that not the domain of oAuth to handle? I don't know, but it's a good idea. You could store the result in a cookie so you don't ask them again in the future.
    – Reactgular
    Commented Nov 29, 2012 at 0:12
  • It might be, and the behavior I'm seeing is specific to the omniauth gem for RoR. It appears to simply trust that whatever user Facebook says is logged in is the right one, and doesn't give the user much opportunity to say "no, that's not me, use this account instead," with the exception of cancelling the operation, changing user accounts on their preferred provider, then trying again from scratch...
    – BrMcMullin
    Commented Nov 29, 2012 at 0:17

Whenever you see an opportunity to NOT require the user to do something, you should take it. And NOT requiring them to either make up or reuse a password is a win-win situation - you don't make them do work and you don't have to worry about the huge expense of dealing with a breach that leaks passwords.

The whole purpose of letting someone else do the authentication, is that you don't have to deal with all of the baggage that comes with it.


One of the reasons that they don't usually ask for a password is the fact that people don't trust giving passwords out.

Passwords are often reused on sites. Therefore each time someone enters a password for a new site they are potentially giving away their sensitive information.

Another reason that passwords aren't used is you are trusting the site that you have done OAuth with to be your authentication provider.

Unless you are intending to adequately hash and salt the passwords you are actually removing security from the users. Doubly so if your site isn't running over SSL.

Its not impossible its not necesarily a bad thing but it may put people off.

Finaly reason is it removes a lot of the convenience of single sign in.

Comments Generally its a good idea to time out someones active session. That stops the shared computer thing mostly. However for some reason this usually isn't done with OAuth/ OpenId

  • 1
    xkcd.com/792 about password reuse. I can't post images at the moment.
    – Athas
    Commented Nov 28, 2012 at 23:51
  • Ah, I was unclear about this in my question. I'll edit it accordingly.
    – BrMcMullin
    Commented Nov 28, 2012 at 23:52

Answering the Edit not the origional question. Yes its perfectly acceptable to show the user some of their own non sensitive information in order to prove:

  1. That your the site you say you are.
  2. That their account is already associated.

Yahoo do something similar where by the user uploads an image which they call a security seal. The idea being that this image proves that it is yahoo that they are communicating with.

Lots of blogs post the image of the currently logged in facebook account and say answering as "Athas" when you try to comment.

On a useability scale though it may just be better to show this in whatever area of the page you associate with the user. i.e. in stackexchange you can see your username at the top.

Otherwise its just an extra hoop for someone to jump through.

Or do it on a time basis.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.