Single Sign-On (SSO)

What is Single Sign-On (SSO)?

Single Sign-On is an authentication scheme that allows users to log in once and gain access to multiple applications or systems without re-entering credentials for each one. With SSO, a central Identity Provider (IdP) validates the user’s identity and then issues authentication tokens or assertions that other applications (called Service Providers, SPs) trust. This means a user can, for example, sign in to an SSO portal or their domain (e.g., via Active Directory) and thereafter launch their email, CRM, and file-sharing apps without separate logins – the SSO mechanism transparently handles authentication to each. Under the hood, common SSO protocols include SAML 2.0, OAuth 2.0/OpenID Connect, and Kerberos (in Windows environments). 

For instance, in a SAML SSO flow, when you attempt to access a service, you are redirected to the IdP (if not already signed in) for authentication; once authenticated, the IdP sends a SAML Assertion to the service, confirming who you are and often including authorization attributes. The service validates this assertion and logs you in without asking for a password​.

How does it affect identity security?

SSO is important for identity security on multiple fronts. First, it reduces password fatigue and reuse. Users with many accounts often reuse passwords or use weak ones – SSO cuts down the number of credentials users manage, encouraging stronger, unique credentials for the one account they do use (often combined with MFA at the SSO login)​. This lowers the risk of credential compromise. 

Second, SSO centralizes authentication logging and control. Security teams can monitor one IdP for suspicious logins, enforce one set of password/MFA policies, and immediately revoke access to all integrated applications by disabling one account. Without SSO, revoking access means offboarding the user separately from each system – a slower, error-prone process. Indeed, many breaches exploit this lag. 

Third, SSO can raise the security baseline for all applications. Some legacy or third-party apps might not support MFA or advanced risk detection on their own, but when front-ended by an SSO IdP that does, those protections apply universally. However, SSO also concentrates risk – if an SSO account is breached, it potentially opens access to many systems at once. That’s why securing the IdP is critical (harden it, use MFA, monitor it closely). 

Case studies

A real-world incident underscoring the value of SSO (and the perils without it) is the 2019 Airbus breach. Attackers targeted VPN accounts at Airbus suppliers to pivot into Airbus’ network. Those suppliers did not use Airbus’s SSO; they had their own logins which were weaker and got compromised. In response, Airbus accelerated federation and SSO programs with suppliers to ensure any access into Airbus systems went through Airbus’s central strong authentication, rather than shared passwords at suppliers. 

On a more common note, business email compromise (BEC) often exploits users reusing passwords across services – e.g., a user’s email and a third-party CRM use the same credentials, attacker gets in via the weaker app then uses those creds on email. With SSO, that risk drops because users aren’t maintaining separate credentials and the SSO account likely has MFA. Many organizations that fell victim to BEC (leading to fraudulent wire transfers) subsequently rolled out SSO + MFA for all apps, closing the gap that allowed the attack.

‍