You may not be familiar with the term “single sign-on” (SSO). SSO became popular in the 2000s and 2010s as companies tried to simplify access across their growing online ecosystems for employees, contractors, and sometimes customers. As organizations adopted more specialized applications, requiring users to remember separate credentials for each one became increasingly inconvenient. SSO addressed this by allowing users to sign in once with a single set of credentials and then access all applications and assets they were authorized to use. Over time, the boundaries between individual applications blurred, and the idea of a broader “ecosystem” took hold. Today, most large application providers—including Google, Apple, Microsoft, and others—use this model: one login, many applications. This approach is also extending to third-party applications, which can support SSO by integrating with the hosting ecosystem.
If a user is logged into an ecosystem using an SSO, they can go to any app they have authorization to use, if that application accepts an SSO login from the hosting ecosystem. This access can be as valuable to casual users as it was for corporate users. So valuable in fact that it has acted as an incentive to application providers to offer such access for a paid subscription fee. The value proposition being that the user can reduce the number of credentials they need to know.
An argument against SSO is made that using one account to access many services creates an unnecessary dependency on the SSO account. If your primary SSO account is compromised, the impact can be significant because many connected services may be accessible through it. In that sense, it can become a “master key.”
However, it is easy to overstate the risk by suggesting that if one site using SSO is compromised, attackers can simply use that same key elsewhere. Modern SSO systems are specifically designed to prevent this. Third-party sites do not receive your Google, Apple, Microsoft or Facebook password; they receive authentication tokens that are not usable on other sites.
An SSO often improves security because it reduces the number of passwords in circulation and password reuse, and allows users to benefit from stronger protections such as multi-factor authentication, passkeys, account monitoring, and suspicious-login detection. For most users, these benefits outweigh the risks of giving up control of their own credentials.
A more balanced message would be that SSO is often more secure than managing many separate passwords, but because it concentrates access in one account, that account should be especially well protected. The issue is not unique to any one SSO provider and is not accurately described as causing a domino effect from one compromised website.
Wayne Kurtz
Birkdale Computing 