All SSO security is not created equally

Single sign-on (SSO) solutions integrate with a company’s identity provider (IdP) to allow users to authenticate to multiple applications via a single log-in. By reducing the number of access points and employee credentials, SSO reduces a company’s attack surface. SSO also makes it easier for IT and security teams to provision and revoke access to applications via the IdP instead of manually managing access for every individual app.

SSO grew to prominence in an era of static applications, managed devices, and perimeter-based trust. However, despite SSO’s adoption, companies continue to struggle with untrusted forms of access and an overall widening of the Access-Trust Gap, which SSO cannot stop. For example, SSO solutions can leave many applications and users unsecured.

But even when SSO does protect something, questions may remain about how well it is being secured. The efficacy of SSO solutions varies widely, depending on factors within the solution itself, and the size and ability of the team managing it.

This blog will provide an overview of some of the ways in which SSO solutions can be more or less effective depending on their implementation, the factors that teams will need to consider when rolling out SSO, and solutions that can help supplement it.

SSO offers flat security

SSO offers some centralized access controls, but lacks crucial insight into the context of access at the individual application level. In some ways, SSO replicates the shortcomings of the old “castle and moat” version of network security. It offers a protective layer of security around access, however, once a user has crossed that layer, SSO does very little to reason about what happens within its barrier.

Jason Meller, VP of Engineering at 1Password, points out, “SSO is a pretty flat form of security, and it’s missing a lot of the details that let admins make responsible decisions about managing access. It shouldn’t be a yes/no binary where SSO grants everyone the same level of access – you need to understand what someone will be doing in an app. When was the last time they used it? Why are they assigned this role? Who granted them permission? Signing in with SSO and centralizing permissions has some benefits, but they’re minimal compared to this larger access problem.”

Even for managed identities, SSO doesn’t have much ability to reason about who is accessing applications and why. For instance, SSO can show certain log events, like when users last accessed an application. But to find this information, the admin will typically need to have specific users or apps in mind to monitor. There are few systems in place to alert when, for instance, a particular user hasn’t logged in for an excessive amount of time, which can be invaluable for tracking improperly offboarded users and detecting unused licenses.

SSO can also be used to provide access to only needed apps, according to a user’s group or level. However, within the apps themselves, SSO has no real oversight over what access that user has or how they use it. Furthermore, most SSO providers have limited ability to tailor access based on context like device health or app sensitivity.

For instance, admins may want to allow developers to access Slack through any personal device but want to require that GitHub is only accessed from the user’s secure, managed device. SSO cannot allow that level of nuanced, granular access control.

Authentication protocols vary in their security

SSO solutions may use multiple different authentication standards to verify identities. Each standard offers a different level of security. Unfortunately, calculating the relative security provided by any given option can depend on many factors.

In comparing SAML and OIDC, for instance, teams must consider various elements of its implementation. SAML has been a long-held standard of SSO, meaning it’s built more directly into the infrastructure of web applications. It’s also broadly considered the go-to security standard for enterprise environments.

However, SAML is also highly complex and difficult to manage. As Michael Grinich and Zeno Rocha explained for Stack Overflow, “SAML integration can be difficult to implement and check… if every layer isn’t thoroughly checked, malicious actors can misuse the payload.”¹ Teams without ample time and resources may have trouble configuring it properly, which could easily offset any security gains.

OIDC is lighter-weight, simpler to manage, and better suited to mobile authentication. However, it also works by adding an authentication layer to the OAuth 2.0 authentication protocol. OIDC offers flexibility and is better suited to many modern apps, but it can inherit OAuth 2.0’s complexities or vulnerabilities if not implemented carefully.

These are only examples of some of the complexities of comparing SSO standards. Overall, teams have to consider many factors when deciding what protocol will offer the best security gains.

SSO can be difficult to manage

Regardless of the protocol, SSO’s overall security depends heavily on the size, skillset, and capacity of the team maintaining it. Even basic tasks – like integrating apps, managing token settings, or troubleshooting failed logins – require specialized knowledge and ongoing oversight.

CISA explicitly names this complexity as a barrier to SSO adoption for SMB and commercial companies, where teams are often smaller and less specialized. They write, “setting up the advanced SSO features often requires specialized technical knowledge and expertise as well as a time commitment.”²

In other words, SSO is often only as effective as the team behind it. In many organizations, that team is already stretched thin.

This results in a troubling dynamic. The companies most in need of centralized access control often lack the resources to implement it securely. When SSO is misconfigured, it can create a false sense of protection, leaving unmanaged access hidden behind a security façade.

SSO requires strong MFA

Though SSO is considered compatible with a Zero Trust security architecture, it remains true that if the SSO is compromised in any way, multiple applications are put at risk. To mitigate that risk, SSO needs to be protected by strong authentication.

However, much like SSO, not all MFA solutions are created equally. Email and SMS MFA are notoriously insecure, for instance. Meanwhile, in the 2022 Uber hack, the attacker was able to use MFA prompt fatigue – combined with a bit of phishing – to breach MFA safeguards on a set of stolen contractor credentials. From there, they leveraged that access to steal administrator credentials with full access to Uber’s cloud environments. This provides another example of how bad actors can overcome MFA.

Many companies hope to use SSO to put them on the path to passwordless authentication. This provides critical security through the use of phishing-resistant authentication factors, like biometrics or FIDO2 keys. Unfortunately, AI agents and bots will be unable to use many passwordless factors – with biometrics being one obvious example. Teams will need some way of securely provisioning them with credentials and MFA codes.

Meanwhile, FIDO2 and WebAuthn – the cryptographic standards behind most passwordless factors – both operate independently of SSO. This means they can suffer from many integration issues plaguing SSO solutions. Okta, for instance, provides a list of cases where WebAuthn may be limited or unsupported.³

Individual applications have varying security within SSO

It falls upon third-party SaaS vendors to design and implement their app’s integration with SSO. This means that many of SSO’s security abilities depend on the application providers, who have been known to misconfigure various settings when designing SSO implementation.

In an article for CSO Online, Joe Sullivan and Atul Tulshiibagwale discuss some common misconfigurations in SSO integrations. Session limitations are one particularly concerning example. “While SSO providers can set restrictions on token usage, it ultimately depends on the application provider to implement and enforce these limitations…many applications incorrectly configure session tokens by failing to enforce expiration, properly validate authentication tokens, terminate sessions when users log out, or implement or validate binding.”⁴

This came into play in the 2023 Okta breach, which resulted in the compromise of their customers’ session tokens. As CSO John A. Smith reported on DarkReading, “…on Nov. 23, 2023, Cloudflare detected a threat actor targeting its systems using session tokens from the Okta breach. This indicates that these session tokens were not expired a full 30 to 60 days following the Okta breach — not as a routine course of business, and not in reaction to the breach itself.”⁵

Session timeouts and limitations are a critical component of SSO security. If these are misconfigured, they can put a company’s security at risk while also jeopardizing its ability to comply with regulations like HIPAA*,* PCI DSS, and others.

SSO doesn’t eliminate password risk

For many organizations, SSO is not accelerating passwordless adoption but is actually slowing it down. That’s because SSO relies on each application supporting federated login standards like SAML or OIDC, and passkey adoption in those apps often requires significant integration work. Even when passkeys are supported, they’re usually tied to the SSO provider itself, making it hard to enforce consistent passwordless experiences across the entire application ecosystem. Organizations find themselves in a fragmented environment where only a subset of users and tools benefit from stronger authentication, while the rest remain stuck in the password era.

While SSO can centralize access control for federated applications, most deployments still rely on passwords behind the scenes. SSO does nothing to eliminate password-based authentication for third-party SaaS apps, legacy systems, or shadow IT – where password reuse, shared credentials, and insecure sign-ins are still the norm.

In fact, password practices often deteriorate under SSO because users assume SSO has it covered. In reality, poor password hygiene, shared credentials, and exposed secrets still put companies at risk — with 68% of breaches involving credential compromise.⁶

In summary, SSO’s security capabilities depend highly on a team’s size and ability to manage its complexities. Furthermore, security varies depending on the protocols used and the individual SSO integration designed by third-party SaaS vendors.

SSO supplements and alternatives

For companies that already have SSO, there’s little reason to retire it. When properly configured, SSO can bring many security benefits to corporate environments.

Even so, companies with SSO need to consider supplementary solutions to secure the various applications and users it leaves unmanaged. Companies without SSO will benefit from exploring alternative solutions that better serve their needs until they can afford the investment of budget and technical expertise.

A new category of security solutions, Extended Access Management (XAM) is designed from the ground up to close the Access-Trust Gap. It complements tools like SSO but goes far beyond their limitations.

Continuous trust verification

Traditional SSO is built on a single binary event: you log in once, and then you’re trusted. But in today’s environment, that one-time trust model breaks down. Users switch devices, connect from personal endpoints, and use AI agents that never “log in” in a traditional sense. It’s not enough for a user to log into the SSO; admins need to ensure that those users are accessing systems through secure and compliant devices.

Trust can no longer be a single event. It must be continuously verified. That’s why 1Password Extended Access Management replaces static login-based trust with real-time context-rich verification of user and device status. Through 1Password Device Trust, admins can ensure that sensitive resources are only being accessed by devices and users that are currently trusted to do so. This helps to manage the risks posed by legacy users and compromised credentials.

SSO does not enable a path to passwordless

SSO adoption often gets mistaken with passwordless maturity. In reality, the two are not synonymous. It’s critical to demand strong authentication factors for every app at a company, whether that app is secured behind SSO or outside of its protection. In either case, there’s an undeniable security mandate to phase out passwords in favor of more phishing-resistant forms of authentication.

A true transition to passwordless security requires more than SSO federation. It demands visibility into where passwords are still used, prioritization of credential risks, and structured support to help employees and IT move to stronger, phishing-resistant authentication methods.

For example, 1Password Device Trust also provides a phishing-resistant authentication factor in the form of device identity. Users can’t access applications from any device that isn’t trusted and associated with that user. This means that bad actors, even with phished credentials, won’t be able to authenticate to systems as long as they’re using an unknown device – offering a means beyond SSO to govern access to critical applications.

1Password Extended Access Management also enables your team to see where passwords are still being used at your company. It then uses the 1Password Enterprise Password Manager (EPM) to facilitate the transition from passwords to passwordless authentication factors. EPM can, therefore, secure authentication for apps where SSO is too expensive or incompatible. 1Password’s EPM also allows developers and administrators to securely provision the necessary credentials to AI apps and agents.

Unlike SSO, which is limited exclusively to apps that support its identity provider infrastructure, 1Password brings passwordless capabilities to every application and identity, including those that SSO can’t reach. By helping organizations identify where password risks still exist and providing the tools to replace them, Extended Access Management paves the way to a future where mature passwordless security is achievable.

Build security into applications

Solving the issues of secure authentication to SaaS apps also requires looking more closely at the applications themselves. It’s necessary to ensure that application developers have the tools they need to build secure access controls into their offerings.

For example, as AI agents become increasingly embedded into enterprise workflows, developers need a way to securely manage credentials, secrets, and private information within each application.

The 1Password Developer SDK provides a solution for AI developers to seamlessly integrate credential storage, authentication, and access management into their apps. Through secure vaults and end-to-end encryption, the 1Password SDK ensures that AI agents only retrieve the credentials and secrets they are explicitly authorized to use. This enables app developers to ensure that their applications can only access sensitive information within a secure, policy-driven environment.

SSO won’t suit every team

“The bottom line is that SSO is no less secure than an infrastructure without it, and is almost always more so.” – Josh Fruhlinger, CSO Online⁷

The above quote is accurate to a degree. The issue is that this isn’t a compelling enough security promise when weighed against SSO’s high cost and complexity – particularly for smaller organizations.

When considering rolling out SSO, teams need to make an honest assessment of their current bandwidth and capability to support the solution. Without proper governance, SSO will not offer its ideal benefits, and may even lead to a false sense of security that can propagate more vulnerabilities within a company’s overall security.

Companies of any size need to be aware of SSO’s limitations and costs when they choose when and how to invest in it. From there, every company should also consider alternative or complementary solutions to address SSO’s shortcomings and close the Access-Trust Gap.

Want to learn more about how 1Password Extended Access Management can enhance or replace traditional security solutions? Reach out for a demo!

Rachel Sudbeck

Content Associate