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.
