SSO explained: Single sign-on definition, examples, and terminology

What is SSO?

Single sign-on (SSO) is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. Its beauty is in its simplicity; the service authenticates you on one designated platform, enabling you to then use a variety of services without having to log in and out each time.

In the most common arrangement, the identity provider and service provider establish a trust relationship by exchanging digital certificates and metadata, and communicate with one another via open standards such as Security Assertion Markup Language (SAML), OAuth, or OpenID.

Implemented correctly, SSO can be great for productivity, IT monitoring and management, and security control. With one security token (a username and password pair), an administrator can enable and disable user access to multiple systems, platforms, apps, and other resources. SSO also reduces the risk of lost, forgotten, or weak passwords.

Why is SSO important?

SSO is important because the number of enterprise services and accounts to users’ needs controlled access is ever-expanding, and each of these services needs the sort of security that normally provided by a username/password pair. But provisioning and administering all those accounts can become a burden for administrators and users who struggle to choose strong passwords for multiple accounts. Single sign-on centralizes the process for both admins and users while maintaining secure access to applications.

There are a few different standards that can be used to implement SSO, but they all follow the same basic underlying pattern. The key is that they make it possible for applications to hand over responsibilities for authenticating users to some other application or service.

From the point of view of the system administrator, the SSO platform represents a one-stop shop where user IDs can be managed. When an employee leaves a company, for instance, their ability to log in to a host of internal applications can be revoked all at once.

Single sign-on terminology

There are three key terms you need to know in SSO lingo:

• Service provider: In an SSO context, this is an application or website that a user might want to log into—anything from an email client to a bank website to a network share. Most platforms like these would include their own functionality for authenticating users if they were standing alone, but that’s not the case with SSO.

• Identity provider: With SSO, responsibility for authenticating users is fielded out to an identity provider—generally, the SSO platform itself. When the user attempts to access the service provider, the service provider will consult with the identity provider to ensure that the user has proven that they are who they claim to be. The service provider can put parameters around how authentication works: for instance, it can require that the identity provider use two-factor authentication (2FA) or biometrics. The identity provider will either ask the user to log in, or, if they’ve logged in recently, may simply let the service provider know that without troubling the user further.

• Tokens: These are small collections of structured information that are digitally signed to ensure mutual trust, and they’re the medium by which the service and identity providers communicate. It’s through these tokens that the identity provider will tell the service provider that the user has authenticated—but, crucially, the tokens don’t include authentication data like the user’s password or biometric data. As a result, even if the tokens are intercepted by an attacker or the service provider’s systems are breached, the user’s password and identity remain secure. The user can also use the same login credentials for any service providers using that identity provider.

Single sign-on example

Imagine you’re the user in an environment with single sign-on and you’re trying to get access to some resource on a server. The sequence of events for how SSO works goes like this:

1. You attempt to access the service provider—again, this generally is an application or website you want to access.
2. As part of a request to authenticate the user, the service provider sends a token that contains some information about you, like your email address, to the identity provider, a role played by your SSO system.
3. The identity provider first checks to see whether you’ve already been authenticated, in which case it will grant you access to the service provider application and skip to step 5.
4. If you haven’t logged in, you’ll be prompted to do so by providing whatever credentials the identity provider requests.
5. Once these credentials have been validated, the identity provider will send a token back to the service provider, confirming that it’s authenticated you.
6. This token is passed through your browser to the service provider.
7. Once received, the token is validated according to the trust relationship that was set up between the service provider and the identity provider during the initial configuration.
8. The user is granted access to the service provider.

If you want a closer look at the guts of the messages being passed back and forth in these sorts of transactions, check out the examples here from OneLogin. These examples are based on SAML; you can dig into the full XML code for the kinds of assertions being passed from the identity provider to the service provider in the scenario outlined above.

Single sign-on security benefits

SSO’s biggest security benefit in the enterprise is that it allows an organization to scale up the number of users—and the number of associated logins—without either sacrificing security or becoming bogged down in endless account provisioning. Thanks to automated credentials management, sysadmins are no longer required to manually take care of all the employees’ access to the services they want. This in turn reduces the human error factor and frees up IT time to focus on more important tasks.

Other benefits include rapid provisioning for cloud-first applications; if your SSO implementation supports the rise of open standards like SAML 2.0, the application can be quickly provisioned by an SSO admin and rolled out to employees. SSO can also be combined with 2FA for increased security, and can provide productivity gains and fewer IT help desk password resets.

Is SSO safe?

It would be wrong to suggest that SSO is a silver bullet, however. Challenges around implementing SSO include cost, control, standardization (SAML vs OAuth), and, yes, security. Authentication flaws, like the Sign in with Apple vulnerability or the Microsoft OAuth flaw could allow an attacker to log into a site or service as though they were the victim they were targeting.

You’ll also want to keep in mind that your SSO platform will have to integrate into your larger organizational IT architecture, and you’ll need to think carefully about how to do so while maintaining your overall security posture. For instance, an SSO system may make it impossible for downstream security tools to detect the originating IP address of the user attempting to log in to your system.

That said, single sign-on often provides a stronger layer of security than an alternative in which users must maintain separate logins to multiple enterprise services. In particular, SSO reduces the attack surface of your infrastructure: your users have fewer passwords to remember and log in fewer times a day. Centralized administration also makes it easier for administrators to impose security measures like strong passwords and 2FA across the board. The bottom line is that SSO is no less secure than an infrastructure without it, and is almost always more so.

Single sign-on vendors

There are several types of SSO solutions to consider, from commercial offerings to roll-your-own open source platforms. For more on how some top SSO tools stack up and different approaches and considerations, see “Single sign-on solutions: How 9 top tools compare.”

SSO tools from top vendors include:

• Duo/Cisco SSO
• Idaptive Single Sign-On
• ManageEngine/Zoho Identity Manager Plus
• MicroFocus/NetIQ Access Manager
• Okta Single Sign-On
• OneLogin Single Sign-On
• PerfectCloud SmartSignIn
• Ping Identity PingOne
• RSA SecurID Access Suite

Full article attribution is made to its original source and author.