The SSO tax is killing trust in the security industry

Application providers charge fees to implement single sign-on but don’t deliver a full SSO experience. Threat actors are taking advantage of the situation.

We hate asking an organization we are helping secure to pay the single sign-on (SSO) tax. For those not familiar with the phrase, it refers to the license upgrade fee that many cloud software applications charge for unlocking the functionality needed to integrate with an SSO provider. See: The SSO Wall of Shame for a long but not exhaustive list.

Unfortunately, what happens next is worse. After you pay that tax, you don’t always get what you thought you were buying, and attackers have figured that out. Session management beyond your SSO is comparable to the Wild West — and that is not just limited to scenarios such as the Okta HAR files debacle, but also account compromises caused by threat actors leveraging phishing attacks and EvilProxy and other infostealer malware.

It is only when you dig into the functioning of authentication tokens in practice that you uncover that cloud software application providers are complicit in these attacks. Some application providers charge you the tax but don’t actually invest that fee in implementing the SSO experience that you expect in return. During testing, we found that some application providers that enable SAML integrations with SSO providers don’t provide the security controls we believed would be in place. They force us to pay extra to integrate their application with our SSO platform but leave us vulnerable to account theft in ways we did not expect.

What is supposed to happen with single sign-on behind the scenes

Most enterprises have adopted an SSO solution and trained their employees to log into company applications only through that portal. Blue teamers cringe at paying the SSO tax but have ultimately accepted that paying is a necessary cost of improved security. SSO simplifies the end-user experience of logging into lots of different applications directly, reduces the risk of bad password practices, and centralizes the authentication process that represents the door most threat actors enter through.

With SSO in place, we can do things such as insisting that authentication be done through a FIDO2 multifactor authentication (MFA) option, dictate the length of authentication sessions (to force users to reauthenticate after a specific period of time), and we can force a logout of all sessions (such as when a person is no longer an employee of an organization). Those are powerful controls we have been led to believe come out of the box when we deploy an SSO solution.

As an employee logs into an SSO platform, a series of steps occur behind the scenes to authenticate the user and grant access to authorized applications. These steps involve the exchange of authentication tokens between the user’s browser, the SSO platform, and the application being accessed.

Authentication tokens

Authentication tokens are incredibly powerful — they grant the person with access to a token direct paths to sensitive environments. As a result, SSO providers empower companies to place limits on sessions to enhance security and prevent unauthorized access. These limits include:

1. Binding: Authentication tokens can be bound to a specific device or browser or URL, ensuring that the user can only access authorized applications from where the token was originally placed.
2. Session length: Authentication tokens can have a limited lifespan, after which they expire and require renewal.
3. Session termination: Authentication tokens can be automatically terminated when the user logs out of the SSO platform or when they close their browser.
4. Location or IP restrictions: Authentication tokens can be restricted to specific geographic locations or IP ranges.
5. User-initiated session termination: Users should have the ability to terminate their active sessions from any device or location, effectively revoking all associated authentication tokens.

By implementing these limits through their SSO provider, organizations can significantly enhance the security of authentication tokens, protect user identities, and mitigate the risk of unauthorized access to sensitive information. That is, they can if the application provider does their part in the process.

Authentication token handoff

There is a big gap in accountability in one aspect of the deployment of authentication tokens. Even if the enterprise directs the SSO provider to set any or all the above limitations within the authentication token issued, those session limitations might not actually be implemented by the application provider. To understand the breakdown, here are the steps of the SAML authentication token exchange process when an employee logs into a SSO platform and accesses an application:

1. User requests access to application: The employee clicks on a link or opens a bookmark to access an application that is integrated with the SSO platform. The application sends a request to the SSO platform for authentication. If the user is using a mobile app, the mobile app opens a browser to navigate the user to the SSO platform.
2. User logs into the SSO platform: The employee enters their credentials (e.g., username and password) into the SSO platform’s login page. The SSO platform verifies the credentials against its identity provider (IdP), which holds the user’s identity information. Sometimes, a browser-based user may start with this step.
3. The SSO platform validates the credentials and does two things:
   1. It sets its own cookie in the user’s browser, which helps it identify the user so that every request doesn’t result in challenging the user for credentials.
   2. It generates an authentication token, sometimes in the form of a JSON Web Token. This token contains information about the user’s identity and sometimes about the user’s access permissions.
4. The SSO platform sends a token to the application via the browser: The SSO platform redirects the browser to the application, sending the token as a part of the redirection request.
5. The application sets a cookie in the user’s browser based on the SSO platform-issued authentication token, by trusting that the IdP of the SSO platform has done the appropriate validation before issuing the token.

Application provider single sign-on failure

All our assumptions break down at that last step. Research suggests that there is a huge failure by application providers regarding the enforcement of session limitations defined by SSO providers. While SSO providers can set restrictions on token usage, it ultimately depends on the application provider to implement and enforce these limitations within their application. We did some random testing and found disturbing answers that were all over the place. We also learned there have been quite a few studies over the years documenting that 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.

How single sign-on sessions are being compromised

There are many ways attackers are abusing these vulnerable authentication tokens and compromising identities, including:

• Phishing: Attackers create fraudulent websites or emails that mimic legitimate login pages, tricking users into entering their credentials, including their authentication tokens. Evilginx2 is one commonly used tool for this attack.
• Malware: Malicious “infostealer” software can be installed on a user’s device to steal their authentication tokens.
• Session hijacking: Attackers can intercept the communication between a user’s browser and the SSO platform or application, capturing their authentication tokens.
• Side-channel attacks: Attackers exploit vulnerabilities in the SSO platform or application to extract authentication tokens from memory or browser storage.
• SSO providers are compromised directly: They expose the tokens, for example in HAR files received from customers.

What we need fixes for single sign-on

Application providers must do better at adhering to the guidance provided by SSO providers on authentication token content. Here are some ideas for addressing this issue:

• Clear communication and documentation: SSO providers should clearly communicate their authentication token requirements and guidelines to application providers in a comprehensive and easily accessible format.
• Compliance monitoring and enforcement: Security teams deploying SSO solutions should establish clear processes for monitoring and enforcing compliance with SSO provider authentication token guidelines. This may involve vendor questionnaires and regular audits of application code, integration testing, and the use of security tools to identify and address non-compliance issues.
• Standardize token formats and protocols: Encourage the adoption of standardized token formats and protocols, such as JSON Web Tokens (JWTs), to promote interoperability and reduce the complexity of token validation and compliance.
• Enable token revocation: The Continuous Access Evaluation Profile/Protocol (CAEP) is a relatively new standard from the OpenID Foundation’s Shared Signal Working Group. It is based on an earlier blogfrom Google. It specifies how events such as session revocation can be conveyed in near real-time to peers that share user sessions, such as identity providers, applications, device management providers, or endpoint security providers. Technology based on CAEP has been in use internally at Microsoft since 2020 to be able to dynamically revoke sessions across Azure AD, Teams, and Exchange Online.
• Collaborate with browser makers: Browser developers should play a bigger role than they do now. Browser-based approaches reduce the burden on application developers, bring more consistency to bear on technical approaches and open opportunities for novel approaches. For example, there has been much discussion around whether browsers can ensure session tokens are bound to specific browser instances. Earlier efforts such as Token Binding, which was implemented by Microsoft Edge on Windows 10, were not very popular. Google abandoned efforts to build Token Binding in Chrome. The new IETF mechanisms of DPoP to sender-constraint tokens are a good starting point. They need to translate to actual solutions that applications and browsers can incorporate. There is an interesting proposal for Microsoft Edge based on DPoP, called BPoP. Something like this should be implemented in all browsers.
• Implement transparency programs: We should push application providers to transparently demonstrate their ability to adhere to SSO provider authentication token guidelines.

Stopgap solutions for the SSO problem

Before some of these solutions are adopted, there are steps we can all take. If you are responsible for identity and access management at an organization, have you audited the authentication tokens you rely on to ensure they operate as expected? Have you considered what compensating controls you could put in place? Are there security products that can do that auditing for you or otherwise mitigate this risk in your environment? Do the security questionnaires your company sends to potential SaaS application providers ask how they configure authentication tokens?

It is going to take a serious collaborative “security by design” effort between SSO providers, application developers, and browser companies to repair the broken SSO environment we currently operate under. We single out application providers for criticism in this article because they so often charge an upgrade fee to integrate with SSO. If they are going to charge us a tax, they need to step up or share in the blame for the compromises that will continue to happen. Hopefully, we won’t need to add a column to the SSO Wall of Shame to document their failures.