What social logins do for you

Sending usernames and passwords through Twitter, Facebook, Google, etc. takes the burden and technical complexity of security away from you. Most systems provide a few commands in back-end code, such as Ruby, that connect to remote servers, create and handle tokens.

They also make logging in easy for end users, who don’t have to remember yet another password.

The disadvantages arise from compromised security. If the users’s social media password is stolen, everything for which they use that username/password is at risk. Luckily large companies take security seriously.

• Facebook’s ongoing security feed
• Twitter’s guide to security
• Google’s security policy

How it works

When a website presents users with, say, a Google login form, entering their credentials and tapping “submit” sends their username, password and application ID to Google. This application ID is a series of characters that belong to each ZURB app such as Notable, PatternTap and Forrst. This ID tells the login service where to redirect the user if their credentials are valid.

Assuming the user’s credentials are correct, Google (or social login service of your choice) sends a request token to the web host that serves the website itself.

But that information could come from anywhere. To confirm, the website sends yet another token, called the access token, back to Google. Essentially the host says, “I just received this request token. Is it valid?”

If Google replies “yup, that’s legit,” then the host gives the user’s browser access to the secure site, usually in the form of a session or cookie.

The really great part: You don’t have to worry about much of this. Simply apply for an application ID Google, Facebook, Twitter etc. and use that ID when you create a form on your website. Make sure the form points to the correct URL in the social login service of your choice. The servers handle the rest.

One caveat: Most services require you to add code to your website. For example, Google requires a bit of JavaScript before the </body> tag. Facebook and others have similar requirements. These code snippets help validate users’ browsers, thus cutting back on hack attempts.

Choosing a login option

Twitter, Google, Facebook, LinkedIn and Pinterest all offer social logins. Choosing which is best for you depends on your goals and your users.

For example, we wanted to give our users one login for all of our properties. Initially we offered Twitter, Google, Facebook and email, but found that to be overkill.

We plan to simplify the next iteration of our platform by using only Google and email. Login screens are sometimes the first contact users have with our sites, certainly each time they visit; we felt that Google gave us the best first impression. It says “ou’re about to step into a professional, enterprise-level online tool.” Twitter and Facebook felt more casual — more social — than the look we wanted to give.

Because we used people’s email address as a unique identifier, we knew we could also use Google users’ logins. People who logged in with Google could still log in with their email, no problem.

Aside from going directly to Facebook, Twitter or Pinterest, third-party services exist that allow users to use a platform of their choice.

• Omniauth: Simple way to add social media login to your Rails application.
• Passport: Makes it super easy to add all sorts of social media logs to your Node.js application.
• Meteor: A new web framework and includes social media authentication out of the box.

---