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.\n\nUnfortunately, what happens next is worse. After you pay that tax, you don\u2019t 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.\n\nIt 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\u2019t 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\u2019t 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.\n\nWhat is supposed to happen with single sign-on behind the scenes\n\nMost 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.\n\nWith 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.\n\nAs 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.\n\nAuthentication tokens\n\nAuthentication 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:\n\nBy 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.\n\nAuthentication token handoff\n\nThere 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:\n\nApplication provider single sign-on failure\n\nAll 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.\n\nHow single sign-on sessions are being compromised\n\nThere are many ways attackers are abusing these vulnerable authentication tokens and compromising identities, including:\n\nWhat we need fixes for single sign-on\n\nApplication 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:\n\nStopgap solutions for the SSO problem\n\nBefore 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?\n\nIt is going to take a serious collaborative \u201csecurity by design\u201d 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\u2019t need to add a column to the SSO Wall of Shame to document their failures.