One of the alarming things we hear is that social integration is an easy way to deploy basic user management, on a service that will maintain all the security and hosting (in theory). There are some good reasons to connect with Facebook, but ease of deployment is not one of them.
Social login is a particularly useful plugin, one that saves your users from having to remember yet another password. With the average user keeping track of 25 accounts, it’s also a very compelling solution. Social login is simple for users and gives useful data to developers.
It also happens to make user management tricky.
TL;DR: Social login isn’t as straightforward as it seems.
Beyond eliminating the pesky registration form, social login can support engagement and viral loops to grow an app’s user base. This usually requires deep permission to access a user’s social graph. For instance, social login on Goodreads grants the app extensive write access; when a user clicks “Okay,” their Facebook network will get blasted with all their recent literary inclinations. If users don’t want to spam, they must hunt down and turn off sharing.
True, Goodreads explicitly requests and is granted permission, but nonetheless, the default setting frustrates and angers some users. A better example of write permissions is MapMyRun, which asks users to determine the privacy of each event. This gives users both the safety to control who can see their location, and the ability to share their athletic successes…and promote MapMyRun.
Social login can also benefit applications where users need social proof: with AirBnB, users can see how they are connected to potential guests, which helps them select someone who is less likely to trash their place.
Moral of the story: don’t pull a Farmville and go overboard. The tides of awareness and sensitivity to sharing are moving towards privacy and control.
B2B apps are almost always better off avoiding social login. First, enterprises tend to call privacy snafus ‘data breaches’, and the consequences are magnified. Second, most B2B applications don’t rely as heavily on virality.
If social login is a hard requirement (and even if you are developing a consumer app):
- Pay attention to each platform’s recommendations on permissions
- Only make calls for data you absolutely need.
- Be very careful what you write back to the social platform: business users are even more sensitive than consumers about what they share.
Beware these outright misleading claims:
- Social login is developer-friendly. Native is not. True statement if you’re comparing traditional on-premise identity solutions to social login. But it’s not the only easy way: many modern frameworks simplify rolling out your own login system, and Stormpath can replace it entirely.
- Users want convenience! Don’t underestimate concerns over how much personal information social integrations give a third party. This excellent Mailchimp post demonstrates how little social login will help a B2B signup funnel.
Not everyone uses Facebook or Twitter. More than one third of Americans are not on Facebook, and other networks have significantly less penetration. It’s worth considering if the demographics of your user base match the demographics of the social network you want to authenticate with. It’s also worth keeping in mind that usage and critical mass on social networks can be fleeting and fickle. Remember MySpace?
Further, privacy scares like Prism make people who do use them hesitant to consolidate their online identity. And others won’t trust you with their social data. Unless you’re willing to wave these people away, you need to build a native system.
When you build your own user management using a framework (or even Stormpath!), the decision of what data to store—and how it’s used— is between you and your users. Social platforms, by contrast, can and do change their policies about how you can access and handle their users’ data. If you go with a framework or service like Stormpath, you don’t have to worry about building functionality against a policy that could later change.
Another hard truth is that even if you use social login, you will still need to build user tables to handle authorization and access control. An authentication attempt with social login isn’t going to return a payload that includes a user’s role, so you will need to manage and store that locally.
Fortunately, options have become easier and more cost-effective in recent years. We’re admittedly biased towards our own service, a user management and auth. backend that works with any programming language, but framework-specific options like Devise for Rails or user authentication in Django are very well supported too. Furthermore, most frameworks have plugins for social login, so you can build what’s best for your users. Soon, Stormpath will too!