How to Use SSO — an Introduction

Think back to the last time that you had to come up with a password for an account on a new website or app. Remember the headache of debating whether you should go with your old password that you remember, or come up with a new one that might be more secure but easily forgotten. Now imagine a service called Single Sign-On that totally eliminated this headache for you, and allows you to easily store all your passwords.

Why SSO is Important

Before we dive into the nuts and bolts of what SSO actually is, and how the tech works, we can set the scene a bit and consider why such a service even exists. Why do we need it?

Most Passwords Are Not Secure

As mentioned in the intro, when most people intend to come up with a new, highly secure, outlandishly difficult password, but invariably end up going with one of 2-3 canned passwords they have in their repertoire, usually a sequence of 8-10 letters and numbers with a character or two thrown in.

In fact, this study by Panda Security found that, on average, over 50% of users of any given database reuse passwords, or barely modify them making them easy to hack. This is known as password fatigue. This password strategy means that if any one of those sites gets hacked, or somebody happens upon your password, then the security at all of those sites is compromised — you will have to change all of those passwords to assure yourself that nobody can get your data, and even then it might be too late.

This apathy, more than the impetus of hackers, is the greatest cybersecurity risk in play today. If we don’t create secure passwords, or we reuse passwords on sketchy websites, then it’s all too easy for a malicious user to gain access to all of our accounts. For a humorous take on this, check out this XKCD comic strip.

IT Managers Are Tired of This

If you lose your password, you’ll naturally want it replaced. While some websites have automated password retrieval services, like backup emails or codes, some offices don’t have those systems in place. As a result, a lost password will result in a help ticket to IT, and this will result in a loss of time and productivity, both for the IT manager and for the employee.

SSO services resolve this issue neatly. Studies have found that they significantly reduce IT costs by reducing the number of help desk calls for lost/misplaced/hacked passwords, in some cases by as much as 80%. So they benefit both the user and the enterprise, not only in terms of security, but also in terms of productivity.

How SSO Works for an End User

From an end user’s perspective, SSO services are relatively simple to use. All you need to do is create an account on your chosen SSO provider (Okta, OneLogin, etc) and then choose to sign in with that SSO provider when you create an account on a new website.]

Creating an SSO Account

This is rather straightforward. The first step in enabling SSO for yourself or your organization is creating an account on your chosen SSO provider. The best SSO providers have separate flows for creating a personal account and a company account, so depending on your use case, you’ll want to make sure that the provider supports what you want.

Creating a single user account is the more straightforward of the two, so we’ll focus on the other case: Creating a company account. In the following screenshot, you can see what your dashboard would look like after creating a company account (here, Kisi), and linking an app to Okta (here, Hubspot, the CRM). For this app, as for many others, you’ll need a browser plugin — this is just to give the provider permission to store info on your computer, nothing to be afraid of!

Once you have the account set up, you can move onto the next step, which is linking your existing app accounts to the SSO provider, to ensure a seamless experience.

Linking New Accounts to SSO

In the following screenshot, you can see what this process looks like: It will all happen on the SSO’s dashboard, and from there, you’ll select authorized apps to link. Note that not all apps have the ability to be linked to an SSO provider. They need to be SAML 2.0 compatible, which we’ll discuss more in depth in the next article in this series.

Once you have your accounts linked, the rest all happens behind the scenes, and if you’ve done everything correctly, your information should be auto-completed when you attempt to sign in to your linked account.

The Tech Behind SSO

Behind the scenes, the process is a bit more complicated than what the end user experiences (as all good tech should be).

How Signing in Normally Works

In traditional, non-SSO frameworks, when you attempt to access a website with a required username and password, there are two levels of separation - the user (you), and the domain you are trying to access. You communicate directly with it, and give it your login credentials, at which point it grants you access. Often, your data will then get stored as a cookie in your computer, which is simply a small text file that is stored either temporarily, or semi-permanently on your local machine (at least, until you “clear cookies” on the browser).

In the future, whenever you attempt to sign onto the same domain, it will retrieve the cookie so that you don’t have to go through the process of signing in again. Great! However, when you attempt to sign into a new domain, and you want to use the same login credentials, you will have to manually create a new sign-in cookie. This is because browsers only let the creator website have access to the associated sign-in cookie, for obvious security reasons. Therefore, you will have to repeat the process of signing into every new app you attempt to access, and not only is this time-consuming, it also clutters your machine, since you will need to store a great number of cookies. Here is a schematic of how this process works.

How SSO Improve This

SSO providers both streamline this process and make it more secure. The SSO server comes in as a third party, adding a third layer to this diagram. If domain 1 and domain 2 here opt to both integrate with the same SSO server, then when a user wants to create a sign-in cookie with one of the two, that domain will redirect them to the SSO authentication server (this process is quite seamless — you often will not even have to leave the app, but can do it directly from the app’s interface).

The user will create the sign-in cookie, which will then be linked with the third party SSO server rather than the original domain, and the server will then issue an authentication token to the domain, signing you in. Later, when you choose to sign into domain 2, it will redirect you to the SSO, which will then pull the sign-in cookie from your browser, and issue an authentication token to domain 2, eliminating the need for a second sign-in cookie creation. This diagram should help outline the process.

The authentication server in question is the third party SSO that we discussed, and we can see that only this server has back and forth communication with the browser cookie cache, and in turn, it then sends authentication tokens to the domains for them to grant you access.

Advantages of This Change

First off, you only have one set of login credentials to remember — if the cookies on your machine are cleared, you only need to log back into the authenticating SSO provider once, and that will grant access tokens to all the apps that are integrated with it. If you didn’t have this service set up, and cookies got cleared on your laptop (either because you did it yourself, or because they expired), then you’d need to sign into all your accounts again, many of whose login credentials you’re likely to have forgotten.

Beyond that, these SSO providers are super secure — that’s their job. Whereas most domains favor the functionality of the app over user security, the entire service that these SSO providers are selling is identity and access management. Indeed, there is a protocol that most SSO providers use for this purpose of exchanging authentication data between identity providers (SSOs) and service providers (web apps) - SAML, or security assertion markup language. We’ll discuss that in the next article in this series!

Main Takeaways

SSO is an important innovation in the field of cyber-security. It eliminates all the inherent security risks from password fatigue and password sharing, and makes the whole process of logging in much more secure. If, however, you’re still skeptical about it, you’re welcome to employ the strategy in this other XKCD comic.