What Is SSO?

Despite our best attempts to craft secure and easy-to-remember passwords for the countless applications used at work, passwords remain a weak link in cybersecurity. They are vulnerable to phishing attempts, and are very often reused by individuals, creating a huge security risk. To mitigate these risks, many companies are ditching traditional passwords in favor of single sign-on (SSO) authentication methods. 

SSO has many benefits. The primary advantages are that it limits the number of passwords a user needs to create and remember, while also eliminating the need for service providers to manage accounts.

How Does SSO Work?

SSO relies on two components: an identity provider and a service provider. For SSO to function properly, the application or service being configured for authentication must have a trusted relationship configured between it and the identity provider(s). As with many trust-based concepts in technology, this relationship relies on a signed certificate that’s shared between the two entities. The certificate provides integrity of the user information sent from the identity provider to the service provider or application.

While the signed certificate is required to configure the connection and validate the communication between the identity provider and application, the authentication uses SSO tokens to transmit and validate the user information.  

SSO Authentication Process

1. The end-user browses to the SSO application (i.e. the service provider).
2. Upon requesting to login, which is done by inputting username details, the service provider sends a token containing this information to the identity provider.
3. The user will be redirected to the identity provider’s login website where they can enter their credentials.
4. Once the user inputs the correct credentials, the identity provider will send a response token to the service provider that validates the authentication was successful.
5. Upon receipt, the service provider will validate the sent token against the signed certificate used to set up the trusted relationship.
6. Provided that authentication to the identity provider is successful and the trusted relationship between the two entities is intact, the user will be logged in to the application.

Typically, once this process is complete, a session cookie is created in the browser session, which then preserves the authenticated session. The period of time the session is valid depends on the SSO configuration, though most sessions will be valid for hours or days within the same browser session. When the user exits their existing browser session, the session cookie clears and they will need to re-authenticate to their identity provider the next time they attempt to access the application.

What are SSO Tokens?

SSO tokens are what contain user data required to authenticate a user to an SSO application, which is most often a user ID, email address or other identity claims. These tokens are exchanged from the service provider to the identity provider so the collected authentication information (input by the user) can be validated against the identity provider’s account directory.

Types of SSO Tokens

As IT needs and web applications have evolved and become more sophisticated, SSO providers have introduced different types of SSO tokens to handle various security needs. These are some of the most common:

• Security Assertion Markup Language (SAML): The standard protocol for exchanging authentication information between parties. SAML tokens store user identity data in XML documents and use encryption and digital signatures to keep it secure. 
• Access Tokens: Short-lived tokens that provide access to specific resources and APIs. They are designed to minimize security risks by limiting the time they are active and the amount of data they can access. 
• Refresh Tokens: Tokens used to keep a user authenticated on an application for long periods of time. They work by obtaining ID tokens and requesting new ones if an application needs authentication again. 
• JSON Web Tokens (JWTs): Self-contained tokens that hold user information and are used for SSO implementations. Unlike other tokens, JWTs can be used in stateless authentication, where a server doesn’t store any session data about a user’s access, providing an extra layer of security. 

More From Katlyn GalloMFA Fatigue: What It Is and How to Avoid It

Benefits of SSO

As mentioned previously, there are numerous benefits of SSO with the most obvious one being the convenience to end-users. For service providers and applications that use SSO, users no longer have to create different accounts to access and use the service. Instead, they can opt to authenticate to the service using an existing identity, like Google, Facebook or Apple. 

This feature indirectly results in security benefits, as the ability to use one account for multiple services reduces the chances of reusing weak passwords. Often, the more passwords a user has to keep track of, the less complex the passwords become. SSO enables us to use one or two accounts to access multiple applications, thereby limiting the number of passwords we need to remember and (hopefully) increasing the chances users will create more complex passwords.

SSO offers benefits to the IT teams as well. Between password reset requests, account lockout issues and endless access requests to various applications, IT staff can spend a lot of time provisioning accounts and resolving access issues when SSO isn’t in place. SSO enables quick provisioning of access to apps, and can even proactively assign users to applications based on their role assignments. Additionally, many SSO providers offer self-service password reset and account unlock capabilities, both of which significantly reduce the amount of users calling into a service desk for assistance.

Risks of SSO

If done carelessly, SSO can lead to extensive immediate access that can pose a security threat if a user’s credentials are compromised. IT teams should use security concepts like the principle of least privilege and role-based access to ensure no user receives more permissions than they need or extensive access to apps they don’t use. Alternatively, if a user’s account is locked out for one reason or another, they will be unable to access all systems or applications that use the SSO account.

In many cases, once access is granted, there is little control over the sessions. Enterprises using SSO should consider using conditional access policies that can provide an added layer of security to SSO. Conditional access allows an organization to use other attributes of a logon. For example, from where is the login occurring and from what type of device? This helps the provider determine the level of risk the login presents. If the request differs significantly from previous successful logins (e.g. if the location of a recent login attempt is different from one that occurred an hour ago) the system may raise a flag. This capability can help IT and security staff proactively identify a potential breach. 

Finally, the use of multi-factor authentication (MFA) with SSO is a must. MFA provides an added layer of authentication that makes it more difficult for a malicious individual to successfully login to SSO services using stolen credentials. This significantly reduces the risk of an unauthorized user gaining access to multiple services or applications using a single account. 

Related Reading From Built In ExpertsYour Organization Needs Zero Trust Architecture

SSO Applications

While SSO is primarily used in the corporate world, many use it for personal accounts as well. When shopping online, many retailers may allow you to create an account or login to their platform with an Apple ID, Gmail or Facebook account. This is SSO in action, as you’re using an existing identity to authenticate to another service or application. 

In the business world, IT teams configure employees’ enterprise accounts to access various business applications. For example, a company may use their enterprise accounts to sign into the Office 365 suite of applications (Outlook, Word, PowerPoint) as well as the corporate network, the intranet and cloud applications like Salesforce, Concur, Dropbox and more.

Frequently Asked Questions