What is Single Sign-On?

The Basics of SSO

What is Single Sign-On (SSO)?

In order to use an application, or access a secure network, you need to identify yourself. This is often done with a combination of a unique username and a password. Nearly everyone is familiar with this method of logging in to a system or application. The combination of a username and password is referred to as credentials, which are a form of authentication.

Decades ago, a single set of user credentials were all that a person needed to do their job. Then, more applications were created that required separate credentials. And still more, as the years went on. Nowadays, a person may be required to log in to as many as 9 applications1 in order to do their job. Each of those applications usually requires their own user credentials.

The rise in the number of applications wouldn’t be so bad if users could have the same credentials for all of them. However, that would create a massive security hole. If one system were breached and the credentials were leaked, then all systems with the same username and password would be vulnerable to unauthorized access.

These difficulties and security risks gave rise to the concept of Single Sign-On, or “SSO” for short. The basic idea of SSO is that every application a person needs can be accessed by logging in only once with a single set of credentials. This may sound very similar to the scenario above, where each system could be accessed with the same username and password, but it’s quite different. In the scenario above, each system held a copy of the credentials in their own database. With a proper SSO solution, those applications don’t have a copy of the credentials—they simply trust what is called an Identity Provider (IdP). Without an actual copy of the username and password, credentials can’t be leaked if one of the applications are compromised.

Before we cover how this works in practice, let’s go over some new terms and definitions.

Identity Provider (IdP):
This is where user credentials are stored. All authentication happens here. There are various popular IdPs available on the market, such as Active Directory Federation Services (AD FS), Okta, OneLogin, and HelloID.
Service Provider (SP):
This is often the application that a user is accessing that requires authentication. When a user opens an application, the Service and Identity Providers talk to each other to verify the user’s identity. If the Identity Provider positively identifies the user, then they are allowed into the application.
An assertion is a package of information that is sent from the Identity Provider to the Service Provider.The content of an assertion varies by SSO protocol (e.g., SAML, OAuth, or OpenID) but it usually contains the user's unique ID, name, and various other attributes. It is signed and encrypted by a certificate that both the Identity Provider and Service Provider have access to. This lets the Service Provider be sure that the information is from a trusted source.

In general terms, SSO works by having an established trust between the Identity Provider and the Service Provider. This means that when the Identity Provider says that the person accessing the application is Bob Johnson, the Service Provider believes this and logs the user into Bob’s account.

This trust is established by the administrator of the systems. Information from the Identity Provider is passed to the Service Provider, and vice versa, along with a certificate. When a user opens an application, the Identity Provider uses the certificate sign and encrypt an assertion. This assertion is then sent to the Service Provider, instead of the user’s credentials. It is then decrypted by the Service Provider and verified.

By establishing this trust, Service Providers don't need to store any user credentials. This greatly reduces the likelihood of compromised credentials in the event of a data breach.

Now that we know how SSO functions in general terms, how does a user go about accessing an application? How does a Service Provider know to check with an Identity Provider?

Most Single Sign-On Identity Providers come with application portals. These are often web-based applications that a user can access from anywhere in the world. Once a user logs into the portal with their network credentials, they’re given access to any number of applications they need to perform their work. Once the user chooses an application, an SSO assertion is sent to the Service Provider with the user’s information. If the assertion is accepted, the user is taken to the application, and off they go! This type of SSO activity is called “IdP Initiated”, because it came from the Identity Provider itself.

But what if a user doesn’t go to the portal first? What if they point their browser directly to an application such as GMail? In those cases, the Service Provider knows what to do based on the user’s username or email domain. Instead of credentials, they store the Identity Provider information and know where to route the authentication request. This type of request is called “SP Initiated”, because the SSO request came from the Service Provider.

In addition to increasing security by lowering the risk of compromised credentials, a good Single Sign-On solution provides easier application access for end users. This can directly translate into higher morale and productivity, and possibly even increased revenue.

There are risks associated with a Single Sign-On solution, however.

With an SSO solution in place, the Identity Provider and any connected authentication systems become highly critical. In the event of a loss or disruption to one or the other, access to all SSO-enabled applications is effectively denied. Additionally, with all applications being accessible through a single set of credentials, it becomes much more important to protect those credentials and make sure that they are not shared or misused. It’s highly recommended that any SSO solution is combined with an additional level of authentication, such as Smart Cards or One-Time Password tokens.

Despite the risks, a Single Sign-On solution carries many benefits to any sort of organization. Presently, SSO is a hot topic at all levels of all industries. Everyone wants their business to perform faster and be more streamlined, and SSO is a key factor in achieving those goals.

[1] https://www.businesswire.com/news/home/20170918005033/en/Information-App-Overload-Hurts-Worker-Productivity-Focus