What Is Single Sign-On (A Non-developer's Guide)

Everyone who uses the internet agrees that life would be better with fewer logins. For users, logging in is a hassle that interrupts whatever they were trying to do and forces them to remember their password. What's bad for user experience is doubly bad for businesses, because a frustrated user is more likely to walk away from a transaction or browse a website without logging in.

The solution for a world with fewer logins is single sign-on (SSO), which allows a user to log in once and automatically gain access to a suite of connected applications. Companies that implement single sign-on properly benefit from improved user experience and heightened security. Below, we'll explain how single sign-on works and the differences between a good SSO policy and a bad one.

What Is Single Sign-On?

Single sign-on is a method of logging in that lets a user enter in their login credentials (usually a username and password) just once and automatically be logged into multiple websites or applications. Single sign-on is one element of identity and access management (IAM), which is the entire set of tools and protocols governing how users log in and gain access to data.

An SSO solution is like a library card. A library card lets you check out books from every branch in a library system instead of having to get a separate card and a separate account for each one. This makes life easier for patrons, who can now access books from all of the local branches instead of just one. And it makes things easier for the organization because they know how people are using their services (and who owes late fees). SSO operates according to the same principle, except instead of uniting the different library branches in a city, it unites different digital properties used by a single company.

The most widely known customer-facing example of single sign-on is Google's G Suite. Users log in to their Gmail accounts, and when they navigate to Google Docs or YouTube, they're automatically logged in. While end-user authentication is the most widely known use case for SSO, its also used in business-to-employee (B2E) settings.

Some companies also use SSO for their employees, so a single set of credentials grants access to a set of applications. For instance, if an employee logs into their employee portal, they'll be immediately logged into Slack and Zoom with their employee ID.

SSO is a part of the broader concept of federated identity management, which allows for someone to use a single identity across multiple different systems. SSO refers specifically to a single login giving a user access to multiple properties that are still part of a single organization.

Federated identity, meanwhile, means using the same identity to log in to properties owned by multiple organizations. It's possible to have a federated identity that isn't a single sign-on. For instance, an app could enable social login (logging in with something like Facebook, Google, or Apple ID) but still only use that login for a single property.

How Does Single Sign-on Work?

On a technical level, SSO works by having users give their credentials to the SSO solution instead of logging in directly to a website or app. The SSO solution, in turn, checks these user credentials with the company's authentication server (a database of credentials) or identity provider.

An identity provider is a service that stores and manages user identities on behalf of an application. For end users, common identity providers include Google and Facebook. Enterprise identity providers include Microsoft Active Directory, Azure AD, LDAP, and G Suite. Users can log in using an account they've already created with a separate identity provider, which saves them from filling out a new registration form. Using an outside identity provider saves businesses from having to store this information themselves on an authentication server. That's a security advantage for businesses because having databases full of passwords can make them targets for hackers.

When the SSO solution confirms that a user is logging in with the correct credentials, it issues them a token. Then, when they go to a new page, the token confirms that they're already logged in and don't need to do so again. There are multiple ways this interaction can take place using Security Assertion Markup Language (SAML) or Open Authorization (OAuth). For our non-developer purposes, the primary difference between these two is that SAML is used to verify a user's identity (authentication), whereas OAuth controls what resources users are allowed to access (authorization).

Most SSO solutions also include single log-out (SLO), which means that logging out of one site automatically logs you out of the rest.

Single Sign-on Challenges and Benefits

The right SSO solution can create more streamlined user experiences, improve analytics, and increase security. Despite this, SSO adoption has been relatively low, even among businesses that use other cloud-based identity solutions. According to a 2019 Bitglass report, 86% of companies currently use cloud applications, but only 34% use single sign-on (SSO).

This slow adoption rate is due to security concerns and the technical challenges of implementing SSO in-house. Each of these issues deserves attention, but there are solutions for each.

SSO security risks and solutions

With SSO, a user's login credentials act like a skeleton key that unlocks multiple applications. Unfortunately, the more doors a password opens, the more damage a hacker can do with it. That danger is greater for users who reuse their passwords. One of the biggest cybersecurity risks in recent years is credential stuffing, in which hackers use credentials stolen in one data breach to hack into other sites. It's an effective tactic, precisely because many people use the same passwords for everything.

On the other hand, SSO can actually reduce the chance of compromised credentials because it reduces "password fatigue." The fewer passwords people have to create, the less likely they are to reuse old ones.

Still, the best way to ensure that SSO doesn't hurt security is to combine it with strong authentication protocols like multifactor authentication (MFA). MFA, also known as two-factor authentication (2FA), asks users to give additional credentials that prove who they are in the event of a suspicious login or which engaging in risky behaviors (such as accessing payment information).

Companies don't want to use MFA for every login: doing so will create too much friction for customers, so they need a customizable approach. Contextual MFA lets companies determine the situations in which to ask for more credentials. For instance, if a user is logging in on a new device, an MFA solution may ask them to confirm their identity. That may mean sending a verification code to their phone or email or using biometrics, such as a fingerprint.

The other critical element in keeping SSO safe is controlling session length (how long users stay logged in) based on risk. For example, a banking app might automatically log out users after a few minutes of inactivity. A video-streaming site, on the other hand, doesn't need to be so strict about access control and can allow for sessions that last for weeks before they ask users to verify their identities again.

SSO implementation challenges and solutions

When companies try to design their own SSO solutions in-house, they run into some common and potentially expensive problems. For one thing, integrating identity across different types of directories is a challenge, especially for companies using legacy applications. Getting these applications to communicate is akin to trying to connect LEGO blocks with Lincoln Logs. Likewise, it's challenging to design an SSO solution that's compatible with different devices and operating systems, such as Android and IoS products.

Then there's the issue of user migration. Let's return to our library analogy and imagine that, until recently, all the local libraries kept their own databases of users, and now they're trying to combine them. This creates problems because some people have accounts at every branch and possibly have different information on file with each one. Migrating all that data into a single source of truth and correcting it as you go can be a huge headache.

That's why it's simpler and often more cost-effective for companies to use a third-party SSO solution instead of building one from scratch. With an outside SSO provider, integrations have already been solved, migration is simplified, and SSO can simply be plugged in and switched on.

While some companies offer SSO as a stand-alone solution, it's usually part of a suite of services offered by an identity-as-a-service (IdaaS) company. The advantage of using an IDaaS provider for IAM is that it includes the tools you need to use SSO safely, like customizable MFA. Whether you're looking to implement SSO for your end users or your employees, the right IAM solution is the one that includes the integrations and customizability you need.

The Right SSO Solution Helps Everybody

When an SSO solution has the right security safeguards, it can streamline the authentication process and lead to fewer headaches for all parties. People aren't overwhelmed by a ballooning number of user accounts, and businesses get fewer help-desk calls for lost passwords. It all depends on finding an SSO provider that handles a user's identity securely and efficiently.