Security Concerns with Single Sign-On

The topic of Single Sign-On (SSO) has come up recently with more than one client, where the client was unsure about which services they already had compared with what their needs were. In the technology industry, there is common confusion around what SSO is, what security concerns come with it, and what differences it has from other prevalent phrases and acronyms.

Authentication vs Authorization

Authentication is the process of verifying that someone is who they claim to be. For example, when someone logs into their email account, they provide a username (who they claim to) and a password (proof they are that user). These days, using only a password to authenticate a user isn’t the most reliable way to confirm an identity, as it is not guaranteed that the true user is the only person who knows the password. Using multiple factors for more secure authentication is discussed in the next section.

Authorization refers to whether the level of permission someone has allows them to perform a certain action. For example, an administrator of a system may have permission to change a given user’s password, while that user’s manager may not have the privilege to do so. Management of permissions like this ties into the concepts of separation of duties and least privilege.

What is SSO?

Single Sign-On (SSO) allows a user to log in once and have access to their accounts across applications. It eliminates the need to log into Google to check emails, log in again to see a JIRA board, and log in yet again to see LinkedIn posts.

There are two basic paths a user can take to log into an application (service provider) when SSO is implemented for their organization:

1) The user navigates to an application website to log in and is redirected to the identity provider’s sign-in page for the user’s organization. When the user provides valid credentials, the identity provider communicates to the application that this user is who they say they are. The user is redirected back to the application page, where they are now logged in.

2) The user navigates to their organization’s tenant on the identity provider’s site and logs in. After authentication, the identity provider displays applications connected to the identity provider that are available to this user. The user then clicks on the desired application to be taken there, already logged in.

In either case, the user only has to log in once and navigate to the target application once. All redirection and authentication to the application itself are done behind the scenes while the user sees one or two simple screens and then their application page.

MFA, SAML, and Identity Providers

SSO is not the same as Multi-Factor Authentication (MFA). However, the two are often used in tandem. SSO first authenticates a user before giving them access to their assigned applications. This authentication process uses one or more factors to confirm the identity of the user, which is where MFA is often applied. For more information on MFA, see our previous article, Securing Customer Data Using Robust Multi-Factor Authentication.

SAML stands for Security Assertion Markup Language and is a widely-adopted method of communication between service providers (SPs) and identity providers (IdPs). SAML doesn’t actually send passwords between entities, but rather carries a wrapped and signed (via X.509 certificate) document of a user’s username or email address. The service provider verifies the signature of an identity provider with a fingerprint obtained from previous communication between the two.

Popular identity providers include Okta, Active Directory, and Google Workspace.

Pros and Cons of SSO

Simplicity (+): Remembering one complex password is easier than keeping track of multiple (likely simpler and possibly repeated) passwords. This way, users can get to their applications faster and there are less forgotten passwords for a help desk to reset.

Reduced Attack Surface (+): With users only having one set of credentials and using them in one location, they aren’t running the risk of exposing those possibly repeated passwords across their applications. SSO can prevent credential stuffing, where attackers gain credentials for one application and try to apply them to others.

Access (-): With just one point of authentication, if an attacker can gain access to a target’s account for SSO, they can get to any of the applications assigned to the targeted user. This risk also applies to users sharing a computer, which should be considered when creating SSO policies.

Layers (+): To combat this access risk, products like Okta can require another authentication factor before letting a user through to a more sensitive application.

Availability (-): If an SSO service is down, applications relying on it for authentication are inaccessible. However, many SSO providers offer their clients services across multiple tenants to decrease the likelihood of a complete lock-out of applications. Similarly, if a party outside an SSO solution is its identity provider and it becomes unavailable, so does SSO, and in turn, the applications relying on it. Again, there are several strategies of avoiding perceived downtime of these services.

Authorization (+): A single point of authentication allows for an additional point of authorization. SSO providers often give organizations the ability to restrict access even after valid authentication, depending on various contexts(location, user lifecycle state, etc.).

Zirous Can Help

Every organization needs to protect itself and its information. Depending on the industry you’re in or the type of business you operate, you may need different protections and solutions than your neighbor. Identity and access management is vital to the security of your organization.