What are the pros (and cons) of using “Sign in with Twitter/Facebook” for a new website? [closed]

Question

Myself and a friend are looking to launch a little forum site. I’m considering using the “Sign in with Facebook/Twitter” APIs, possibly exclusively (a la e.g. Lanyrd), for user login. I haven’t used either of these before, nor run a site with user logins at all.

What are the pros (and cons) of these APIs? Specifically:

1. What benefits do I get as a developer from using them? What drawbacks are there?

2. Do end users actually like/dislike them?

3. Have you experienced any technical/logistical issues with these APIs specifically?

Here are the pros and cons I’ve got so far:

Pros

• More convenient for the user (“register” with two clicks, sign in with one)
• Possibly no need to maintain our own login system

 Cons

• No control over our login process
• Exclude Facebook/Twitter users who are worried about us having some sort of access to their accounts
• Users’ accounts on our site are compromised if their Facebook/Twitter accounts are compromised.
• And if we don’t maintain our own alternative login system:
  • Dependency on Facebook/Twitter for our login system
  • Exclude non-Facebook/non-Twitter users from our site

Answer 1

A con I would say is that a user might be paranoid that now they've logged onto your site using their Facebook/Twitter credentials they think that your site has full access to all of their information on those respective accounts.

Answer 2

Please don't do it.

Many people, especially those not based in US won't have a Facebook account and won't create one remembering all that has been said in relation to Facebook and its ignorance of users' privacy.

Contrary to what many believe in, there are lots of people who happily live without those social noise&junk sites and don't give a damn about them.

Why spit them in the face and reject them just because they haven't succumbed to the mass hysteria called Facebook?

Other points to consider:

1. You will introduce a single point of failure by making it dependent on an external system. If they decide to shut down their OpenID or make you pay for it, you're massively screwed.

2. They will gather data about your users and who knows what to do with it. At the very least they will use it in marketing purposes and ultimately make money on it and they won't give you a piece of the pie.

3. Through taking them as an OpenID provider you will further support their quasi-monopoly and help them grow even further. Do a community service and do not contribute to that plague.

Answer 3

Another con: exclude non-facebook and non-twitter users (or users that just don't feel safe sharing their login info to other sites). Or cause them inconvenience by making them create an external account. I personally don't like the single point-of-failure idea that if someone gets my Facebook/twitter login info they can get into any other site that uses the same info. But maybe I'm just paranoid.

Answer 4

I can see it being used as an option, but you'd lose a lot of potential visitors if you required a FB or Twitter login. Even if visitors have FB accounts, many wont want to use them for privacy purposes. I certainly wouldnt want to give some random site personally identifying info.

And you'll still probably need some form of user tracking system anyways, since you may want to track user info related to your site, such as preferences.

Answer 5

A site I frequent has its own local login system/user accounts, but users have the option of linking their account to a Facebook account if they wish. So for those people they have the benefits of easy logging-in if they choose, and no one is forced to use a Facebook login if they don't want to. It works quite well, I'd say.

Answer 6

I played around with using OpenID, Facebook, and Twitter for logins. One time I was just testing it, and I couldn't login using Facebook for some reason. After looking at the Facebook developer page, I noticed their API server was down. So that's a big drawback when users can't login because Facebook is having some downtime. Twitter might have the same issues, as would OpenID.

Answer 7

It really depends what your target market is. For instance, in some target markets, that "exclude non-users" concern is a tiny one (almost all users have them and are happy to share). In others, it's a massive problem.

You can see it here in the answers: Programmers tend to be very careful with security and don't want to give access, hence all the "NO!" answers :-p Non-technical people are less careful about this.

But the obvious answer is do both fb/twitter and your own system if you can. Then everyone's happy.

Answer 8

I have a Facebook account but when faced with a site that wants me to login using it, I do not. If there is an alternative method I will use it. If not, I don't really want to see what's on that site anyway. I hate going to sites and seeing what other Facebook friends have done on that site as well, it's creepy and intrusive of your privacy (especially when I didn't login through Facebook or tell the site my Facebook account).

Answer 9

One con to doing it purely that way -- how do you test locally without complex external dependencies? How do you setup random test accounts? Demo accounts? Non-human user accounts? Typically you need a local authentication scheme to cover these permutations, even if the hope is most users store credentials externally.

Most important -- if you don't have an internet connection, you can't even hack, much less do material work, on your app at all. And, when you do have bugs in authentication or authorization, how can you be sure its not a facebook/twitter/other oauth issue if you can't run something simple and local to make sure your code is correct?

Answer 10

I would say that using an external log-in system can work very well -- look at how openID us used on stackoverflow and stackexchange. The advantage is great: you don't have to code all the log-in system, which is a big chunk out of the initial code-base you can simply ignore, and you don't stand the chance of getting it wrong, and can let someone else worry about what sort of password is sufficient, and how to reset it, and so on. And if they already have an openid somewhere (either from a blogging account, or one they set up to access stackoverflow) they don't need to remember another username/password combination.

The disadvantages are that many users find it a bit confusing, and may not want to create an openid on an external site if they haven't used one already.

Using a facebook login has all those benefits, plus the opportunity to interface with their facebook account if they permit.

The downside is that if you rely on facebook exclusively, you're tying yourself to them: if facebook ever change their API or ban your site, or users such as me refuse to log in to a site that may share data facebook (who are known to not be very cautious when it comes to not leaking that data to other companies). Note that IIRC, even having a facebook "like" or "login" link on your page will let facebook track which logged-in users view your site, a la doubleclick.

So, I would say:

• ideally, you would allow logins with several external sites: openID sites, facebook, google, etc.
• if you have a facebook login form, you don't put it right on the first page, only show it when users click "log in with facebook" (I'm never going to complain about having the option to do so :)).
• To start off, decide which is quickest for you to set up, accounts and passwords, or openID or something else.
• Decide whether it's worth adding accounts and passwords as well or not, if you have external log-in. (But make sure to have at least a couple of external log-in)

Answer 11

I am at the very least, wary of the headliners of social media, and especially of Facebook for their liberal disregard for elective information sharing. This distrust has a compounding factor that the seemingly vast majority of apps I have encountered request all my information, and then information on everyone I know to participate in their app context. Baloney. Government security clearance interviews ask for a lot of information as most would expect, but don't come even close to what FB "demands". I have an account, but its stock, only used for the core features.

That being said, I like federated Id in concept and practice (like openid and open auth in general). I think that using the providers supported by the major web mail providers is hard to argue with from a user perspective, for a couple of reasons. One, obvious benefits of federated Id (such as less pairs of login information to remember or otherwise manage with yet another local login information store app or addin). Second, I trust my email provider to do a fairly good job of guarding my personal information (and by consequence, my inbox) as long as I do my part of protecting my credentials (strength of username/pass, and judiciously control exposure ).

I might consider other Federated Id providers, but they would have to be compelling, per the purpose of Federated Id.

Lastly, integrating a multitude of providers is not necessarily easy. The stackexchange team have commented about the challenges a while ago. If I wasn't on a mobile device I would do the search for you.

Answer 12

Meh, I'm in another camp apparently. To me, the concept of Facebook is one that will stand the test of time. Perhaps it won't be Facebook in the future, who knows. However, going beyond privacy conspiracy theorist concerns (you can control your privacy), my opinion is this sort of service will become "utility". In that you pick up your phone to call someone, you run out to your mailbox to grab the mail... you'll "Facebook" your fiends to get in touch.

We're already experiencing significantly reduced email traffic now that people "Facebook" each other instead. It's only a matter of time, but email will continue to dwindle in usage.

Also, keep in mind that the types of people you want logged into your system may very well be the types who would have a Facebook account. Those that don't, typically (from my experience), aren't going to "participate" on your site anyway (or any site really, for that matter).

The fact is, whether it's facebook or not, a system where everyone can communicate instantly with people they approve of, will be the best candidate for an Internet "single sign on" system. You can't simply dismiss "2-click registration and no-click/1-click login" as small pros, they're HUGE!

For people worried about privacy, what are you putting out there on your Facebook profile that could be damaging if taken? Why are you putting it out there?

My vote (for what it's worth) is go for it! Go hog wild, completely replace your membership system with a Facebook-only system. I have, and my users like it so far.