Authentication: Not necessarily a social activity

For Distill, Engine Yard’s developer conference, we chose to use social authentication to reduce the barrier to entry for our call for papers. We supported Twitter, Facebook and Github.

While developing the site, my concern was that the registration flow be simple, and that it actually work. Once we launched the site, I realized that I had trouble remembering which provider I had signed up with.

Maybe that’s just me (I am terribly forgetful!), but I imagine at least a few other people had this issue. Sure, on the backend we can link multiple accounts, but that means users went through the registration process multiple times. This is not optimal.

For those interested in the numbers, here is how the providers stacked up:

• Github: 59%
• Twitter: 38%
• Facebook: 3%

Why did we make this choice? Probably the same reason everyone else does:

Users don’t want, or need another fricken login to remember, just use Facebook/Twitter/Google+/LinkedIn/Github/Yahoo!/…

This is the primary argument for using social auth. And lets be honest, who wants to be in charge of Yet Another Login System?

But is social auth the best option? Lets explore that.

In favor of social auth for our users, we have:

• One less password to remember
• Possible to revoke access
• Automagic integration with my online social presence (that I can control… if I know how!)
• Users are often always logged into their social sites, so they don’t even see a login screen — a few redirects and it can be avoided entirely.

In favor of our bespoke system… it’s the same thing we’ve been doing for years.

What does Social Auth mean to our users?

Let’s break down what all of these things really mean.

###One Less Password

Is this a good thing? Just like using the same password for everything, using the same social account for everything is not necessarily a good thing.

Sure, we can use an 80 character, expanded charset password on that social account, but “guessing” your username and password isn’t necessarily the only way in. Server security breaches, man-in-the-middle attacks (negated by proper application of SSL), fishing or social attacks are still out there! Just like with a bespoke system.

I personally use 1Password as a tool to maintain a list of the literally hundreds of accounts I have, and their respective login credentials. I generate a random password for every site I sign up for, and never even think about remembering it.

I have my password database stored in Dropbox (which, yes, means I’m trusting Dropbox’s security) so it’s available on all my devices, and it can even function standalone with a built-in web interface!

There are plenty of other free tools even that will allow you to do the same thing (e.g. KeePass Password Safe).

__For me__the one-less-password argument holds little water.

###Possible to revoke access

This one is an argument I rarely hear, but is quite important.__Most__websites (though it’s changing, as people get on the free-data bandwagon) do not allow you to delete your account. And there’s a good reason for this: Your data is valuable to the website, even if you’re not using it! (Remember: if something is free, you [and your data] are what brings value to the business.)

With social auth, you can not only revoke permissions entirely (denying access to your social data that they haven’t yet collected), you can revoke permissions partially (assuming the social site implements that).

I think this is quite important.

###Automatic Integration with Social Presence

Social integration is arguable the main reason for even using social authentication (other than the lazy factor), and it can definitely bring value to our experience.

The point of being social, is sharing things with people, and__good__online experiences are things we want to share. Making that quick and easy is beneficial to both the user, and the business — it’s word of mouth advertising, and is priceless.

However, a lot of users don’t want to be social. Either with your site in particular (“I don’t know this site, why would I want it to see my stuff?”) or in general (“I’m a grumpy curmudgeon” or “I don’t want the government to spy on me!”).

The general answer to this problem, is to make social auth optional. Users can sign up for a bespoke account, or signup via social auth. Or Both.

Unfortunately, I find that when multiple signup options are available — be that bespoke + one social auth, bespoke + multiple social auths, or just multiple social auths — I forget which one I’ve used. Did I sign in with Github? Or did I create a new account?

1Password does help me in some regard here, because it would have my bespoke credentials available, but with multiple social auth options? It’s no help.

###Automatic Login

Automatic login is arguably a good thing — it can allow anyone with access to the computer to not only access the social platform (because you’re already logged in), but who knows what else.

Think about the people who leave their Facebook logged in at the Apple Store, apparently nobody has yet realized you can look at the list of Apps they have authenticated with and then can simply visit that site and choose to login with Facebook. Suddenly you now have access to their Pandora, Instagram, Klout, and 100 other apps you’ve authorized!

Now, it is possible as a developer to require login, at least with Facebook auth — but we usually want it to be easy for our users and don’t bother with it!

What about a middle ground?

Is there a middle ground? We’ve already discussed the pitfalls of providing bespoke + social auth(s), so what else can we do?

I think the best middle ground, is to provide bespoke authentication, and then behind that, allow for social connection expressly for the purpose of being social. That is, make it optional.

We can get some of the benefits of social authentication, by allowing users who have connected their social accounts to use them for password resets, rather than email. Simply ask them to re-verify their social account and once they have, you can direct them straight to the password reset form — no emails getting lost, no tokens, simple.

One final option, is that you can use social authentication__without__getting access to more than the users basic information — especially, you can do it without requesting write permissions. Then, later, you can ask for write permissions should the user wish to utilize that aspect of your site.

Being Socially Responsible — A Social Contract

I have, over the course of thinking about these things, decided how I’m going to interact with my users socially.

1. Social integration is always__optional__.
2. Permissions are granted only as-needed. Ask for the minimum permissions to do the requested action, and no more. When more permissions are needed, ask again.
3. __Always give the user the final say__on what gets posted — I will always allow my users to edit the message, and never insert automated text on the end — except the URL to thing they are sharing.
4. Never automatically post _anything. This is really part of the previous one, but it’s better to be explicit.

This is my social contract, it will be publicly posted on my site, and presented when users look at the option to connect their social accounts. I think this is the responsible way to interact with my users, and allow them to interact with folks who will hopefully become my users.

What about you? What’s your social contract look like?

We recently announced the Distill speaker lineup and first batch ticket sales. To learn more, visit distill.engineyard.com