Email+password vs. "social" signin

[Lunkhead]

I'm curious how folks feel about the topic of signing up/in to Web sites and applications, specifically around providing an email+password vs. using a "social signin like Facebook, Twitter, Google, etc.

As a user, I'm not really eager to give people access to my Facebook account. I feel less wary of giving them my Twitter account because I don't really put much personal info in there or use it that much. It rarely occurs to me to use my Google credentials. I think I sort of prefer using an email/password, although it generally means getting spammed. But at least I can use an email address I don't care about, one that's not tied to any of my personal contacts/friends/etc. At that point I don't feel like I'm giving much away.

As a smalltime developer, I am seeing an insane amount of spam email+password signups on the Song Fight! Jukebox. I thought if I made it so that you were generated a random password and you had to get the password via the email you provided before you could log in, that would stop spammers. Not only are the spammers signing up, but they are receiving the password email, then using that password to log in. There are >20k of them from the last couple months. I have no spam accounts that signed in via Twitter/Facebook. Frankly this makes me tempted to just switch my site over to social signin only, with no option for signing up with an email+password. I have no resources for dealing with spam accounts, whereas, Twitter, Facebook, Google, etc. have whole departments dedicated to fighting spam accounts.

So personally I'm conflicted about the subject, and wondering how others feel about it, as users, and for a few of you, as developers.

[jb]

As an app developer, if you do signups via Facebook, you're in control of how much you ask for-- a little or the whole kit n' kaboodle.
As a user, you're in control of how much an app can see of your profile-- a little or the whole kit n' kaboodle. You don't have to let them see anything, and you certainly don't have to allow an app to post on your behalf.

So you can limit it to basically just using your Facebook credentials. (I'm not certain what minimum aspects of a profile are required to be passed when using Facebook auth for a web site.)

This lets you not have an email/pass on a thousand websites-- they just have a token from Facebook and never see your email or password. (It's also, I suppose, a single point of security failure...)

So I guess I'm saying that in my opinion social signin schemes are a good thing. I certainly use them whenever they're an option. But knowing what I do for my job, you probably would guess that to be my opinion.

JB

[Lunkhead]

You do get control over how sites can access your Facebook data, but, it's pretty complex and fluid. I suspect most people don't understand it, or if they think they understand it right now, it could change significantly, and most folks wouldn't really be motivated to try to keep up with FB's latest access changes. So I totally understand the many folks I've heard from who just don't trust social signins.

Here's the bare minimum that FB gives out, without an app having to ask for more access:

https://developers.facebook.com/docs/re ... iend-list/

your friend list
id
name
first_name
last_name
link
username
gender
locale
age_range
Other public information ( https://www.facebook.com/about/privacy/ ... ublic-info )

I guess the friend list part also highlights something I'm not always comfortable with about social signins. It's not that I'm giving them just my own personal info. I'm giving out my friend/contact list which could potentially lead to other people being spammed or having their info compromised, because of me. I would love it if, for example, Facebook would split out friend list as a separate permission that an app must ask for.

[irwin]

Trusted third party is a very useful authentication model.

I do not trust Google (Facebook, Twitter, et al.) to be that third party.

[Lunkhead]

If you don't trust them, who do you trust?

[jb]

songfight!

[fluffy]

I like OpenID as an auth mechanism, but mostly because I run my own OpenID server and I know exactly what OpenID credentials can do - nothing at all.

I'm okay with OAuth for Twitter as third-party authentication because it's one less password for me to deal with or worry about getting stolen (and Twitter isn't exactly lifestyle-critical or anything), although I can't help but worry about what happens if an app developer's OAuth credential store gets compromised. Is there precedent for that happening? In theory Twitter can just revoke the API key quickly but in practice they can be slow to act on things like that... Also, OAuth was intended for a completely different use case than simple user authentication or identity management, and doesn't solve the underlying problem of centralized authorities (unlike OpenID which does solve it incredibly well).

username+password-per-site is obnoxious and I wish OpenID were a bit more frictionless and more widely-adopted. I do use it wherever I can.