Social logins are just about de rigueur. Consumers don’t want to create new accounts, so sharing or piggy backing on existing credentials they already use can be a great solution. That is the key to social login, extending a user’s existing social media credential to enable access to other web sites and services. It has obvious attraction for the user, but it has great benefits for the site’s owner as well. It can enable the owner to get better data about customers while avoiding the pitfalls that come with being an identity provider.
But how does a web site implement social login?
Many sites contract with a third-party provider of social login solutions to ease the integration process. These companies handle the setup and maintenance of the login service to minimize coding and effort on the part of the site’s owner. Using APIs or add-ons, the site owner need only add the app and configure it to meet specific needs.
Companies like Janrain can set up social logins for a site, embed the products in the web site, create the application and handle the protocols and data exchanges. The web site just has to place a piece of code and then Janrain handles the communication, says Marla Hay, senior product manager at Janrain.
But what happens behind the scenes? Or what if you want to build it yourself?
The specific implementation process varies between social identity provider and protocol. For example, to include a Google login it must be configured using a specific identity protocol. But LinkedIn, Facebook or one of the countless other options may require a separate workflow and even protocol.
Most identity providers use one of three protocols – OpenID, OAuth 2.0 or OpenID Connect – to control the backend functionality. Hay says OAuth is the most common protocol Janrain encounters, although she notes that OpenID Connect has been gaining popularity since it’s ratification last year.
Widgets.com launches social login
To describe the implementation process, imagine that the company Widgets.com wants to get out of the business of managing its own user name and password based access system for online clients. They decide to move to social login, opting to allow customers to choose between Google, Facebook and LinkedIn for accessing the Widgets.com site.
For terminology purposes, in this example Widgets.com is the site owner, Google is the identity provider and OAuth 2.0 is the identity protocol.
Stats show social login a necessity
77% of consumers prefer social login to traditional registration
88% of consumers have encountered social login before
51% of consumers use social login
64% of consumers who frequently leave sites due to forgotten login information say social login should be offered as a solution
67% of consumers are willing to share some personal information via social login in exchange for a more personalized experience
91% of consumers who use social login are satisfied with the experience
Widgets.com starts by creating an application at the specific identity provider they wish to enable for social login – in this case it will be Google using OAuth 2.0.
The application contains key information that Google will need to know about Widgets.com in order to interact during the authorization process. This includes the callback URL, which tells the Google where to redirect the user once the authentication process is complete. It also includes a key and secret, which enables Widgets.com to identify itself to Google during the authentication process.
When the consumer arrives at the Widgets.com website to log in, they are redirected to a Google endpoint. At this point the consumer is presented with a list of things Widgets.com would like to access. These are called “scopes” and can include information about the user such as name or email, or actions, like posting a comment to a Google+ circle.
The consumer will log in to their Google account and either approve or reject the request to authorize Widgets.com to obtain data or act on their behalf.
Some identity providers will enable the consumer to select line-by-line which permissions they wish to grant. Others take an all-or-nothing approach, where the user rejects the authorization altogether if they don’t wish to approve the requested scopes. The scopes available vary between identity providers, depending on the function of the social provider.
Once the consumer authenticates, Google sends the approval, along with an authorization code, back to the callback URL that Widgets.com listed when creating the application.
Once Widgets.com has that authorization code, it can make a server-side call to Google to exchange that code for a token. The token enables Widgets.com to retrieve the consumer data or use the permissions that the consumer approved for them. When exchanging the code for a token, Widgets.com will also send the application ID and secret, so Google is assured that the token is sent only to Widgets.com.
Now that the Google login has been successfully implemented, Widgets.com team can conduct a similar process for the other identity providers that they wish to enable for social login.
The amount of time and effort involved in implementing social login varies between protocols, but even within a given protocol, the implementation can vary between providers, explains Hay. Social login implementation can take some effort and time – depending on the expertise of the developer – and always requires understanding the particular implementation of the selected identity provider.
Whether an organization builds the functionality on its own or contracts with a social login provider, the benefits can be great. Research supports that users are more likely to actually register for a site that supports social login. They are also more likely to return for subsequent logins likely due to the increased ease and convenience.