Hendrik Mans - April 04, 2013

The Inconvenient Complexity of Social Logins

It’s easy to assume that adding social logins to your site, maybe even replacing a traditional username/password based setup, heavily simplifies things. “Just add OmniAuth and configure it for a bunch of providers! No passwords to encrypt! No email addresses to verify! There’s a new social network you want to support? Just add your API keys and you’re done!”

However, all this is just the first step, and I’m afraid to say what follows is usually a lot more complex than what this stuff is aiming to replace.

Twitter, Facebook, Persona and Google+ accounts are merely identities, and as you may know from your own digital life, a single person may have more than one of these. So when you develop a site that somehow revolves around user accounts, you’ll need to manage identities linked to these accounts.

And this is not as simple as it sounds. You’ll end up having to solve one or more of the following problems:

  • A user may join your site using their Facebook identity, and at a later stage log in using their Twitter identity, resulting in two separate user accounts on your site. To mitigate this, you’ll have to allow users to merge existing accounts, or ask them to link all of their existing social identities to their account before trying to log in with any of them.
  • Once a user has joined your site using one of their social identities, it’s possible they will eventually quit that particular social network or identity provider, essentially locking them out of your site, with no way to recover their account on your site.
  • In case you’re offering both social and traditional logins – which really is the worst of both worlds –, a user may not remember whether they signed up using Facebook, Twitter or a username/password combination. Unlike social logins, the latter is easy to store in tools like 1Password or your browser’s login storage.
  • You’ll lose a significant number of users who don’t have any or simply don’t understand social logins. Pretty much everyone who’s online understands what a password is. Furthermore, even users who do have social identities sometimes simply don’t trust the providers.

I’m not saying social logins don’t work; just that if you’re trying to reduce complexity by eschewing a traditional login system in favor of them, you should be aware that you’ll have to deal with a whole other type of complexity somewhere else.

Disappointingly (but not entirely surprisingly), I have seen a number of sites trying to solve this by essentially forcing users to create traditional password-based accounts even when joining through a social identity provider. “You’re almost done! Just enter your email address, user name, password, password confirmation and click the verification link in the email we’ll send you!”

So how am I handling this on Early on, I decided to base user accounts on email addresses. When you log in using Mozilla Persona, which currently is the only way of joining or logging in to the site, what you’re really doing is verifying your ownership of your email address, except you don’t have to click some verification link I’m sending you by email.

Persona isn’t without its own share of issues (including some of the ones I described above, but also some technical problems that I will discuss in an upcoming post), so in the future, I may add other ways of verifying email address ownership, maybe even the traditional email-based variety.

This kind of contradicts what I’ve said above, right? I will take care to focus everything on your email addresses, not the opaque, proprietary numerical IDs handed out by a lot of social identity providers (for example, Facebook allows me to get the user’s email address, so I may even add logging in through Facebook in the near future). Part of me hopes that this will allow me to get social logins right; another part is starting to believe that there is no future for them.

Until we reach a verdict, it’s comforting to know that if I ever move away from Persona (or external login providers altogether), I can just revert to a traditional email/password based setup using the data that’s already in my database, without locking out anyone.


Developer dude from Hamburg, Germany. Among other things, runs Not good with descriptions. Don’t follow me on Twitter. ★

Loading comments...

Please sign in to post a comment.