If your website or app doesn’t let users log in with Google – or Apple or Microsoft or [insert fav social app here] – odds are someone has told you it should.
Everyone’s doing it, they say. It’s a best practice.
There’s probably also someone else who told you not to. Users don’t trust it, they say. Or, it’ll mess up your customer data.
At Strivacity, our goal is to engineer unexpectedly simple login journeys. The reality is that using social login has pros and cons. Sometimes it makes things dramatically simpler for your customers to sign in. Other times it throws up speed bumps you may want to avoid.
If you’re on the fence, this post is for you.
Social login is an authentication method that lets customers sign in to your website or app using their existing credentials from another site. Basically, it defers the authentication process to a third party, passing codes and tokens back and forth behind the scenes to confirm the user’s identity.
As in: Login with Facebook. Login with Reddit. Login with…you get the idea.
Social login is widely used in some markets like retail, news and infotainment. It’s also virtually never seen in highly regulated industries like finance, healthcare, gaming, education. Why? It all comes down to the pros and cons.
For your customers, social login creates a streamlined experience. If they’re already logged into Google (and who isn’t), their credentials sail through and there’s one less password for them to remember.
That ease-of-use argument counts double on mobile devices since no one wants to type complex character strings on that tiny digital keyboard.
But while ease of use is one of the big ticket items in the “pros” column for using social login providers, there are lots of other benefits too. Others include:
If you’re leaning towards using a social login provider, one of the most important decisions you’ll need to make is: which ones?
The answer depends on context. The most important question to ask is which sites your customers are already logged into when they visit your website or app. This tends to vary based on the type of website you have:
Consider, too, your customers’ level of trust (or distrust) in those networks. For example, even though using Facebook to login doesn’t give Meta access to your customer’s account on your system, users may still be wary. A social login option that customers won’t actually choose isn’t worth the effort.
If all those benefits are sounding pretty good, why wouldn't you use a social login provider? Well, some of those same benefits can cut both ways – especially if you’re running a site in a highly regulated industry like finance, healthcare, gaming, or education.
User trust and sentiment are prime examples.The reputational benefit of associating your brand with a social network or other third party could be just one data breach (or layoff and CISO resignation) away from becoming a liability.
Social login can also create issues when it comes to account linking. If a customer uses more than one of the social login options you provide, you can wind up with multiple accounts for the same individual and struggle to connect all that rich customer data on the back end. The custom code required to link those accounts steers many a brand away from social login.
And then there’s the challenge of data mapping. While all modern social login providers are built on the OpenID Connect standard for authentication, they often diverge to some extent (Apple diverges the most.) This can create challenges mapping the incoming profile data – name, photo, email, location, etc. – to fields in your own customer identity store. Building in this business logic and resyncing the data when the customer logs in can be a heavy lift, and many CIAM providers don’t offer these capabilities out of the box.
Most of the potential downsides of social login depend on how you choose to implement it. If your in-house dev team is writing it from scratch, every third-party option you add can mean hundreds more lines of code, which you’ll then have to maintain. If you’ve got a CIAM provider who codes their own APIs, you could face a sizeable enhancement project if you need to add or delete a social login option, let alone change your data mapping.
By far the best way to implement social login is to have someone else do it for you.
Your CIAM provider should be able to configure your user journey for any third-party in a way that makes your customers and your marketing team say “wow that was simple!” (aka without a major change request or filing an engineering ticket).
Wanna see how Strivacity does it? Here’s an overview.
Wanna talk specifics for your brand? Our team is just a click away.
Subscribe and never miss out on our blog posts and latest news.
Subscribe and never miss out on our blog posts and latest news.