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 plethora of services without having to log in and out each time.
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.
How does single sign-on work?
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.
In SSO lingo, 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—is a service provider. Most platforms like these include their own functionality for authenticating users. With SSO, though, that responsibility 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.
The service and identity providers communicate via tokens, small collections of structured information that are digitally signed to ensure mutual trust between the parties. 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.
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 architecture
That description should flesh out a picture of a single-sign on system's architecture. 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.
Writing in the Oracle Security Newsletter, Paul Toal dives deeper into SSO architectural patterns, including the less-than-ideal architectures you might need to implement if your service providers can't communicate with an identity provider directly.
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.
Single sign-on example
You might find that description a bit abstract. Let's look at a specific implementation example to see how SSO works in practice. 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 goes like this:
- You attempt to access the service provider—again, this generally is an application or website you want to access.
- 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.
- 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.
- If you haven't logged in, you'll be prompted to do so by providing whatever credentials the identity provider requests.
- Once these credentials have been validated, the identity provider will send a token back to the service provider, confirming that it's authenticated you.
- This token is passed through your browser to the service provider.
- 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.
- 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.
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.
Single sign-on solutions
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." https://www.csoonline.com/article/3405441/best-tools-for-single-sign-on.html?nsdr=true
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
For more on SSO, see:
- 5 best practices to secure single sign-on systems
- Single sign-on solutions: How 9 top tools compare
- 4 authentication use cases: Which protocol to use?
- What is SAML? How it works and how it enables single sign on
- What is OAuth? How the open authorization framework works
- What is IAM? Identity and access management explained