Here’s some of my coverage of SocialDevCamp Chicago 2011, where I was reporting for Dice. For more coverage and job news, check out Dice News.
Registration sucks. Having to reregister for yet another site or build a registration for your service is a pain. Stop registering for new services and stop making people register for new services. Instead, in just a few hours you can use Facebook or Twitter’s sign in system to create a verified user account for your web application or site.
At SocialDevCamp, Chicago, Chris Grove, CTO of KeyLimeTie, a software development company, gave a really good basic presentation on “Social Sign-In 101: What it is, why you want it, and how you can make it happen.” Here is a summary of Grove’s presentation, plus my interview with him as well.
What is social sign-in?
Social sign-in is the ability to enable visitors to register for your website or application using their existing, and often preferred, credentials. If you make people create a new user account, it’s a barrier for users to adopt your service or website.
Use a third-party service such as Facebook, Twitter, or OpenID as an identity provider. The features they provide range from simple authentication to advanced social integration, such as social sharing, posting on user walls.
Don’t confuse authentication with authorization. Authentication is who you are. Authorization is what you’re allowed to do.
Once you authenticate someone, your app will still create a user record that you’ll have to track within your site or application.
Advantages of social-sign in
- Reduces “login fatigue”
- Increased conversion rate when you make it easy to sign in
- Better contextual data – you can connect friends’ activity within the site/app
- Reduces implementation effort (do you really want to write another YAAS (yet another authentication service))?
- Increased security
Why you don’t want to create your own authentication
- Only 25% of users are generally willing to complete a registration
- Of that 25%, 76% give incorrect/incomplete information
- When they forget their password, 45% leave a website rather than resetting a password
- Most users are willing to return to – and purchase from – sites that automatically recognize them.
Source: Janrain 2010 study: “Consumer Perceptions of Online Registration and Social Sign-In”
When don’t you want to do social sign-in?
- Handing off critical site functionality to a third party
- Regulated industries may have issues
- Can increase operational costs – some start off free but once you hit a certain usage there’s a cost.
- Changing APIs can be a problem – Facebook has done this. Twitter dumped Basic Auth. You have to be able to react quickly when there are API changes. Third party providers can manage this.
How do you do social sign-in?
The basic model is you call a site to authenticate a user. In return you get a token. You use that token to get information about the user and then bring it back to your site. You’ll have a unique identifier which will be your user record.
Best Practices for social sign-in
- Use social network branding – People like Facebook and Twitter. Make those logos very prominent. Take advantage of their brand awareness.
- Offer multiple ID providers – Don’t only offer one service. For example, while Facebook is popular, not everyone is using it.
- Provide reasons for people to register – Explain what the value proposition is for signing in. Combine sign-in and registration.
- Use available data to streamline registration – If you ask them to sign in with Facebook and then you prefill a form for them, then it speeds things up.
- Link existing accounts – If user has an existing account, make it easy for them to link it to a social sign-in.
- Give clear confirmation once a user is signed in – They can visibly see it, and there are new capabilities.
- Analyze to optimize – See which identity providers your users are using the most. Note which order the icons are placed in.
Implementation
You have two choices:
- Write APIs for each individual provider, or use an aggregate API.
- Roll your own code, use a stand-alone API, or use an API that calls to a service.
Providers and APIs
- Identity Providers – Facebook, Twitter, etc.
- Stand-alone APIs – HybridAuth (PHP), OmniAuth (Ruby), SocialAuth (Java)
- Service APIs – Janrain, Gigya, Windsoc
If you make a mistake, or choose a service API you don’t like, don’t worry, it’s not too hard to rip one provider out and swap in something else, Grove said.
Stock photo courtesy of Shutterstock.
