A little background on SSO.

Over the course of several years, there have been numerous instances where SSO systems have fallen victim to hacking, including the infamous Solar-Winds Attack on US systems. These incidents exploited vulnerabilities found in VMwares's Access and Identity Manager products, which are designed to offer seamless single sign-on (SSO) capability.

This was not the first time SSO systems were hacked. In late 2018, Facebook made worldwide news due to its SSO implementations having caused the breach of an estimated fifty million user accounts and theft of their personally identifiable information. Similarly, vulnerabilities in SSO implementations have compromised accounts at Google, Oracle, Microsoft, Atlassian, Zoom etc with protocol attacks discussed at peer reviewed conferences.

As futile as it might seem to advocate for ripping out SSO technology from an IT infrastructure, a confluence of events makes this the most opportune time to do so. And, in doing so, it can eliminate the risks within the infrastructure, reduce access control complexity, and eliminate unneeded software and associated Operations, Administration and Maintenance (OAM) costs while delighting users with the new experience.  

An early implementation of SSO was realized as Kerberos in the late 1980's as part of MIT's Athena project. In the following years, SSO was implemented in Security Assertion Markup Language(SAML), OAuth and OpenID to address requirements for the web. All were predicated on the same premise: to help users deal with the burden of passwords when accessing multiple systems and uniformly enforce enterprise password policy.

General Architecture of SSO

The architecture of SSO can be generalized to where users access multiple applications within an enterprise are registered with the SSO service. Their credentials and authorizations to access specific application are stored within the SSO database or Lightweight Directory Access protocol (LDAP) Directory Server. Users must typically pass through a checkpoint, which maybe an explicit component provided by the SSO provider on the network, or integrated within the application, before they can access the application.

The checkpoint is responsible for ensuring users have an Authorization Token from the SSO Service before they are granted access to the application. If they do not have such a Token, they are redirected to the SSO Service where they must be authenticated. Upon successful Authentication, users are issued a token, generally stored within the browser header and returned to the checkpoint. Upon retrieving and verifying the Token's authenticity and integrity and having verified the User's authorization, the checkpoint directs them to the desired application. 

The token is usually cryptographically generated to ensure its security but it depends on the key management controls within the SSO Service. If the security controls are inadequate, attackers can bypass the SSO service for users accounts and generate Tokens with the right privileges by compromising upstream systems in the authorization process.