Knocking Down Doors

Smart start-up lessons for smart start-up people

Single Sign-On: What It Is, How It Works, and Why You Need It

Share This Article

“It’s a dangerous business, Frodo, [running a website that relies on user logins].”- J.R.R. Tolkien, “The Fellowship of the Ring”

What’s the most valuable part of your website?

Your sweet algorithm for compressing video files? Your ever growing collection of original IP? Or, maybe the gaming experience your users get as they hack their way through a place that is basically Middle Earth but that—for legal reasons—is definitely not Middle Earth?

From a hacker’s perspective, none of that matters. Hackers are looking for personal data. Names, addresses, emails, and passwords.

Passwords and other login details may top the list, these days. Yahoo has lost over 1 billion passwords in the last five years. Dropbox had 68 million walk out the door in 2012. Everyone and their uncle has been under fire.

What if you could avoid that headache altogether? Check out the Zomato hack from last month for an interesting insight into prevention and cure. While the company did hold user passwords, 60% of its users logged in with OAuth technology, an open identity management platform, and were put “at zero risk.”

What if your business managed 60%, 80%, or all of its user logins through a similar system? Who’s going to take the time to hack your website when none of your user details are accessible once they get inside? As a bonus, that move to safety also makes the process of signing up easier for users.

Welcome to single sign-on, an identity management structure that solves a bagful of common business problems.

What is single sign-on (SSO)?

Single sign-on (SSO) is an identification system that allows websites to use other, trusted sites to verify users. This frees businesses from the need to hold passwords in their databases, cuts down on login troubleshooting, and decreases the damage a hack can cause.

SSO systems work sort of like ID cards. If I get pulled over for speeding, the police officer doesn’t have to know me personally; they can just look at my license and see that the State of Maryland vouches for my identity.

Likewise, with SSO, your website doesn’t make me prove my identity by checking within itself. Instead, it asks LinkedIn or Microsoft or Google if they can verify my identity. If they can, the site takes their word for it.

Technically, a lot of what’s being called single sign-on is actually a mix of pure SSO and delegation or federation. There’s a sort of jumble between all the platforms, especially as identity-as-a-service providers get into the mix.

I’m going to use SSO here, with callouts when the distinctions really matter.

How does SSO actually work?

Explaining the system in broad strokes is simple, but explaining the process of implementing SSO requires a bit more background. Normally, when you log into a system, the provider of the site or service (website.com, in this example) will authenticate you on its own. Like so:

1. As a user, you hit an intermittent page on website.com that checks to see if you’re already logged in. If you are, it scoots you off to whatever you really wanted—your Gmail inbox, for instance.

2. If you’re not already logged in, you’re presented with a login screen.

3. You drop your email and password in the form, website.com checks those credentials against its database, and then you’re either logged in or rejected.

4. If you’re logged in, website.com will issue some sort of tracker. This could be on the server, or it could be sent over to you as a token.

Now, whenever you move around the site, the system just checks to make sure the tracker—and thus your authentication—is up-to-date.

If you were to do the same thing with SSO in place, it would look more like this:

1. As a user, you hit an intermittent page on website.com that checks to see if you’re already logged in. If you are, it scoots you off to whatever you really wanted—your Gmail inbox, for instance.

2. If you’re not already logged in, website.com presents you with options for authentication via a third party (Google, Amazon, Facebook, etc.). You pick your provider of choice and then log in with that provider, let’s say, Google.

3. Google checks to see that you’re you, checks to see that website.com is the site it’s claiming to be, then authenticates you based on the Google password database and issues a token back to website.com.

4. Website.com gets the token from Google, verifying your identity. It now associates you with the rest of your user data—preferences, history, shopping cart, and so on—and you’re all set.

  • In a true SSO system, you’ll just cruise around from site to site with full access.
  • In a delegated system, Google will return both a verification of identity and set of authorized uses. Website.com might be given access to your name and email, for instance, but not be shown your location or age. (See the example below.)

Great! But why would anyone bother with this?

The benefits for users

There are a few main benefits for users who interact with SSO.

  • Convenience. Users only need to remember one set of login details. By connecting your site to their logins at Google, you ensure that even sporadic users can remember how to log in; they just log in to Google.
  • Transparency. Users know what’s being shared from one system to another—at least in a delegated system. It’s like when you install a new app on your phone and it asks for permission to access your photos, contacts, and bank account. If you’re not happy with those options, you can opt out.
  • Speed. With SSO, users don’t have to go through lengthy sign-up and verification processes. Because Facebook has already done all the email verification and data collection, new users can sign up as quickly as they can log into Facebook.
  • Security. Users also get the peace of mind that comes from knowing that website owner Marlon Rando doesn’t have their password stored in plain text somewhere out in the internet backwater. Facebook continues to be the main point of trust, which allows the user to try new things without fear.

The benefits for your business

That’s great news for your users, but what’s in it for you, the website owner?

  • More user sign-ups. SSO provides a lower barrier to entry, so new customers can sign up easily and securely, by relying on a known brand. Facebook is managing the process, so they don’t worry about your unknown system and brand. Trust is increased, which increases conversions.
  • Less work on the back end. Meaning, you won’t have to futz around with passwords. While reducing your hack risk—the next point—is important, even more important is not having to reset people’s passwords every five minutes. All the authentication and password heavy-lifting is managed by the trusted authenticator.
  • Reduced risk. Finally, you’re removing that tempting pie from the windowsill. Hackers have less incentive to hit your site if you don’t host a ton of login details. You’re also less likely to have a bunch of users with horribly weak passwords poking holes in your site’s overall security.

Building on the base of SSO

Once you’ve got a system in place, you can start to round things out; you can ask for more personal information and build out your customers’ profiles over time. By asking one question here and another there, you increase the chance a user will respond, as they will build a better rapport with your business.

You can also tap into more of the information as Google or Facebook or whoever makes it available. It’s all the benefits of data collection without all the hassle associated with it.

In short, single sign-on and delegation make life easier for you and for your clients.

Getting started

You can hit Capterra’s identity management directory for a full list of SSO providers. Three that come up often in conversations I’ve had are Auth0, Okta, and OneLogin.

If your business is technically inclined—which is to say, you employ software engineers of some stripe—you can also check out the OAuth protocol, which underpins many of the commercial solutions on the market.

As always, if you’ve had experience with any of the topics we’ve covered here or just like to talk generally about your business challenges, drop a line in the comments below or shoot me an email.

Share This Article

About the Author

Andrew Marder

Andrew Marder is a writer for Capterra. His background is in retail management, banking, and financial writing. When he’s not working, Andrew enjoys spending time with his son and playing board games of all stripes.

Comments

No comments yet. Be the first!

Comment on this article:


Your privacy is important to us. Check out our Privacy Policy.