Single Sign-On (SSO) has proven to be a popular Identity and Access Management (IAM) solution within software development, with 87% of organizations in the EMEA region having implemented it by 2022. SSO helps managers and IT administrators streamline user authentication by granting access to multiple applications using a single set of credentials. To fully understand SSO’s potential and, more importantly, its limitations, it’s crucial to understand the distinction between authentication and authorization, as these concepts are at the core of the technology’s benefits and challenges.
Authentication is the process of verifying a user’s identity, typically using the combination of a username and password. Conversely, authorization determines the level of access given to an authenticated user. SSO simplifies both processes largely by relying on Identity Providers (idPs) to handle authentication, with Google Workspace as a common idP.
While SSO streamlines large parts of the authentication process, there are many tasks within authorization that are handled manually. In general, setting up role-based or attribute-based authorization, and handling multi-factor authentication, and fine-grained access permissions are essential parts of implementing security. However, they’re often the root cause of some issues users experience when implementing SSO.
This post covers these issues in more detail, the consequences of their occurrence, and proposes possible mitigation strategies.
What is SSO?
Before diving into the limitations of SSO, it’s important to understand what SSO is, how it works, and why security professionals consider it a best practice. For readers already familiar with the ins and outs of SSO, feel free to skip this section and jump to “The Limitations of SSO in the Modern Security Landscape.”
SSO: A Cornerstone of Modern IAM
As detailed in the introduction, SSO is the process of allowing users to only manage one set of credentials to access a multitude of applications. This heavily reduces the number of passwords users must remember, ultimately enhancing the user experience while helping organizations maintain security and compliance. In other words, SSO addresses some of the biggest challenges of IAM, which is why security professionals see it as a great adoption.
Why SSO is Considered Best Practice
Upon first hearing, you may think SSO principles contradict the well-known best practice of password management: using different passwords for every application. However, the benefits of SSO outweigh the risks associated with having a set of credentials for all applications. Here’s why:
Trustworthy Sources
The single set of credentials used in SSO typically comes from a reliable, well-established source, such as Google Workspace or Microsoft Azure Active Directory. The trust in SSO depends on the idPs you’re using, because it can be assumed that Google and Microsoft provide better password security management than most other companies or platforms.
Centralized Access Management
Just like how users only have to remember one set of credentials, SSO allows IT administrators to only manage one set of credentials (per user). As a result, IT admins can quickly shut down a compromised account with a single action, rather than closing accounts on each platform individually.
Given the growing popularity of password managers, it’s fair to assume that passwords aren’t an issue as long as people don’t reuse them. However, a 2019 study from Google showed that 52% still reuse the same password for multiple accounts, but not all. Yet 13% still reuse the same password for all accounts.
Similarly, a 2022 study by SpyCloud shows that password reuse issues aren’t limited to the general population alone, as 64% of Fortune 1000 employees are reusing passwords for multiple accounts.
So, the ability to close an entire account across all platforms with a single interaction is immensely valuable for IT administrators.
Improving Efficiency With SSO
While there aren’t any readily available statistics on how SSO impacts the efficiency of IT administration, it’s clear that the aforementioned benefits can significantly improve the efficiency of working with IAM. And anyone who’s ever shifted from not having SSO to using it will attest to its efficiency. To provide a few examples, consider this:
- How long does it take to remove an account’s access? How many different platforms do your employees have access to?
- How often do users request password resets?
These are just two examples, but hopefully, they reinforce the point that SSO decreases the time spent on password interactions, irrespective of the number of platforms in use. That said, SSO is still incapable of fully removing the need to interact with each platform, and this is one of the big limitations of SSO.
The Limitations of SSO in the Modern Security Landscape
Although SSO offers a simplified, efficient, and cost-effective identity management solution, there’s a reason for this post covering the limitations of the technology. But the intention of this section is not to frame SSO as a bad identity management solution. It’s still one of the best solutions for most companies—specifically, it’s one of the best identity_ _management solutions, as SSO doesn’t handle access management. That said, there are some important limitations that should be addressed.
Deactivating SSO vs. Disabling User Accounts
Understanding the difference between “deactivating” and “disabling” is crucial when you intend to shut down an account through SSO. When you enable an employee to log into an application like Slack with their Google Workspace account, their Slack account may appear as the user account, but that’s not the case.
Under the hood, Slack is still creating a regular user account in their internal systems, with the Google Workspace account mostly serving to authenticate the employee’s identity—hence the name “identity provider”—and perhaps provide some useful user information, like a name and avatar.
So, imagine you’re going to offboard an employee, part of which includes the removal of their accounts on all platforms (Slack, Notion, Jira, etc.). If you only “deactivated” their Google Workspace account and, by extension, their ability to log in, you may not have “disabled” the Slack, Notion, and Jira accounts, which can have two serious results:
Cost
Failure to disable platform accounts will result in continued inclusion in your total active users count. As of this writing, the cheapest monthly price for a Slack account is $8.75, for Notion, it’s $10 per month. Now imagine incurring costs for tens or even hundreds of “disabled” accounts.
That’s a significant cost accruing over time.
Security
Unfortunately, improper account disabling doesn’t only affect the bill; it also has severe security consequences. Even if you confirm that the employee can no longer log in with SSO, there’s no guarantee that access to the user has been removed.
Session hijacking is a semi-common exploit where a hacker doesn’t need to know your username and password, instead relying on getting access to your browser’s session data. In case you’re not familiar: when an idP authenticates you—verifies that you are who you say you are—it places a cookie (“session token”) in your browser, which is then passed along with every request. Effectively, this means that the platform isn’t using the idP to authenticate you on every request, but rather it verifies that the session token is valid.
This can be a significant security issue. As of this writing, Slack is set by default to allow infinite sessions, which can be configured to 12 hours minimum.
To properly illustrate the consequences this can have, consider the following two scenarios.
Scenario 1: Hack Gains Access to an Account
The popular tech YouTuber LinusTechTips was recently a target for this exact type of hack. The Verge has a more detailed account of what happened. But summarily, a malicious actor got access to an employee’s session tokens. This allowed the hacker to change the channel’s name to “Tesla”, and put a live stream of Elon Musk talking about crypto, then linking to a crypto scam in the description.
Note that this isn’t “just” a YouTube channel; it’s an established company with over 100 employees who are largely tech and security enthusiasts. It’s reasonable to assume that such a company would know how to protect against session token attacks. In their defense, it wasn’t solely their fault, as explained in their video teardown. Yet they ended up as victims of a session token attack that almost caused irreparable damage to their company.
Scenario 2: Fired Employee Turns Malicious
A disgruntled ex-employee may want to cause harm to the company by exposing confidential information or deleting sensitive data. But if you fully disable their accounts, they can’t interact with the company system at all.
However, if you only deactivated SSO without ensuring that the session token has expired, i.e., without disabling the account, the former employee may still have access to the account for as long as the token is active. And as mentioned, the default Slack setting is allowing infinite sessions.
—
Hopefully, this helps you understand better the differences between shutting down SSO versus disabling the user account, and the major impact it can have.
The Security Risk of Manual Permissions
Another gap in SSO is that it only handles authentication, not authorization. That is, you still have to manually handle the permissions of your users to ensure they have the right access. Given that human error is always a possibility, having such a critical part of your security handled manually poses a significant risk.
For example, a misconfigured Web Application Firewall in AWS led to 100 million consumer applications for credit being stolen from Capital One. This resulted in a significant loss of trust in the company and severe financial repercussions in terms of regulatory fines and lawsuits.
The Consequences of Your Identity Management Approach
When a technology like SSO is discovered to have significant limitations, you’ll inevitably see concepts being invented to fix it. One of those concepts is Zero Trust. Although Zero Trust was not developed purely with SSO in mind, it shows how a solid IAM approach, like SSO, can undergo further improvement for stronger security implementations.
Zero Trust and SSO
The Zero Trust link above excellently explains how it relates to SSO. However, here’s a quick overview. Zero Trust is the principle of assuming that no user, device, or system can implicitly be trusted. Instead, every access request is verified and authenticated based on context-aware and adaptive policies. This approach has emerged as a response to the increasingly complex and diverse digital landscape, which requires more dynamic and robust IAM solutions.
The keen-eyed reader may already notice how this impacts SSO. Zero Trust is about verifying and authenticating every request, which as described earlier, is not what happens when SSO uses session tokens. By adopting a Zero Trust mindset, organizations can greatly improve the security of their IAM approach and minimize the risks associated with SSO.
There is one important thing to note: session tokens are not a bad thing. They’re an example of balancing security and user experience. If you have to verify and authenticate against an idP on every single user interaction, systems would be slow. Imagine if Slack had to contact Google Workspace every time you:
- View a channel
- Send a message
- View a message
- Change a setting
- And so on…
Would you still be using Slack?
Combating Permission Sprawl
It was previously mentioned that SSO only handles authentication, leaving authorization management to IT administrators. However, this may not be fully clear to everyone, especially non-security professionals who see SSO as a simple way to implement good security. Therefore, it’s crucial to understand permission sprawl and avoid it with your IAM approach.
Permission sprawl is the uncontrolled and unmanaged growth of permissions that users have access to. It poses several risks, such as:
Overprovisioning
Users having more permissions than they require, which can lead to unauthorized access to sensitive data. Although there are tools that fix existing overprovisioning issues, it’s crucial to consider tools that prevent future issues from even occurring.
Inconsistent access
Users having different permissions across various applications, causing confusion and potential security risks.
Privilege creep
Users retaining access to applications and data after their roles changed or after leaving the organization.
Difficulty revoking access
Inefficient management makes it challenging to revoke permissions when needed. Part of a SOC2/ISO 27001 certification is the commitment to revoking permissions during user offboarding within a specific timeframe.
Lack of visibility
Organizations struggling to maintain an accurate overview of user access and permissions.
—
To overcome these challenges and minimize risk, organizations must implement a proactive IAM approach that continuously monitors, evaluates, and adjusts user permissions. Leveraging automation tools and systems is often a great way to improve the efficiency and effectiveness of your IAM approach, especially at scale.
How to Efficiently Manage Employee SaaS Access
Managing employee access to various Software-as-a-Service (SaaS) applications efficiently is crucial for both startups and enterprises. And automation can play a crucial role in ensuring the success of implementing SSO while addressing its limitations.
Adopting IAM strategies, such as Role-Based Access Control (RBAC) and automated onboarding and offboarding, can improve security by mitigating potential human errors, like what happened with Capital One. Additionally, it will save time in every part of the organization, as IT administrators won’t have to manually provision access—or manually track who has access—and team managers can onboard new people without relying on the IT department.
Considering that audited companies are required to maintain an overview of users accessing different systems—besides it’s a general best practice because it also aids the offboarding process—removing the need to manually track access throughout systems is enough reason for most companies to adopt these strategies.
Ensuring Success with Automation
To recap, every SSO implementation has limitations, some caused by technology and some by human error. Irrespective of the case, automation can ensure security success within your organization.
Having an automated solution to establish and implement clear access control policies, as well as regularly reviewing and updating permissions, is an effective method for combating permission sprawl. Besides, it greatly increases the likelihood of more efficient and effective IAM governance, which is helpful when trying to obtain certifications like SOC2 or ISO 27001.
Some companies are already seeing useful improvements after adding automation to their IAM solutions. FinCompare uses automation to save time and money while improving the employee onboarding experience. viafintech is increasing security acceptance among employees, and Sary is increasing transparency by using automation to manage access.
