SSO concentration risk

When you "Sign in with Google" (or Apple, or Microsoft, or GitHub) on a third-party SaaS, you are not creating an account on that SaaS. You are telling it "the IdP will vouch for me." As long as the IdP vouches, you have an account on every downstream SaaS that accepts the IdP. The day the IdP stops vouching — for any reason, with or without explanation — every dependent service breaks in the same instant.

This is the inverse of the security-pitch argument. The standard SSO pitch ("one strong account instead of many weak ones") is correct about the password attack surface but ignores the availability surface. The unstated assumption is that the IdP is a neutral utility. It isn't — it's a private company that can terminate the relationship unilaterally with no SLA, no contract, no court.

Distributed vs. concentrated

The framing the_smart_ape thread uses (don't sign in with google) is: SSO trades distributed risk for concentrated risk. In expected-value terms the two are roughly equivalent — same probability of total compromise, similar probability of single-service loss. But the distribution of outcomes differs dramatically:

• Distributed (separate accounts, password manager, per-site aliases): failures are independent. Losing one account means re-doing that one signup. The 99th percentile bad day is annoying.
• Concentrated (SSO across the whole stack): failures are perfectly correlated by construction. Losing the IdP means losing every downstream service in the same instant. The 99th percentile bad day is end-of-business.

The case study in the source: a three-year SaaS founder loses Gmail to an unexplained suspension and simultaneously loses access to Notion (specs, contracts), Figma (designs), Linear (tickets), Vercel (deployment, via a GitHub→Gmail recovery chain), and Stripe (revenue dashboard). The friend still doesn't know what he did wrong. Google never told him.

Why the appeal process doesn't help

Account-suspension appeals are read by classifiers, not humans. The famous Andrew Spinks / Terraria case (January 2021) is the demonstration: a high-profile developer lost his account for unknown reasons, the standard appeal did nothing, and the account was only restored after he publicly cancelled the Stadia port of his game and the story went viral. The implicit rule: appeal at scale is gated on having media leverage.

This is not a bug in the appeal process. It is the appeal process. At Google's volume, individual review is economically impossible; the only signal that breaks through is the one that costs Google more than restoring the account would. For users without that leverage, "no" is the final answer.

The right rule, not the right slogan

"Never use SSO" overshoots. SSO is fine for low-stakes services where 30 days of lockout is annoying rather than catastrophic — a podcast app, a news site, a one-off tool you signed up for once and rarely revisit.

The actionable rule is to sort by recovery damage, not by which signup button is more convenient:

If losing access to this service for 30 days would damage your work or your money, do not use SSO. Create a real account, with a real password, real 2FA, and an email alias that doesn't point at your primary IdP.

The thread's adjacent recommendations make the rule operational:

• Break the recovery chain. Recovery emails for password managers, cloud accounts, and domain registrars should not point at the IdP whose loss would orphan them.
• Use email aliases per app (Proton, Fastmail, SimpleLogin, Apple's Hide My Email). If one leaks or one IdP relationship turns hostile, the blast radius is one alias, not your real address.
• Run a pre-mortem. Spend ten minutes imagining your IdP account vanishing tonight. The things you'd lose that aren't trivially replaceable are the things that shouldn't have been SSO'd in the first place.

Adjacent attack surfaces

SSO concentration risk is the availability failure mode. The same mechanism (IdP-issued tokens) has independent security failure modes that don't depend on the IdP becoming hostile — see oauth-token-theft for multilogin refresh-token replay and consent phishing, and google-oauth-domain-takeover for the Truffle Security disclosure where buying a dead startup's domain for $12 unlocked the old company's Slack/Notion/Zoom.

The unifying takeaway: SSO concentrates control on the IdP, and any failure mode of the IdP — termination, breach, architectural oversight — fans out across the whole downstream stack.

See also

• smart-ape-dont-sign-in-with-google — the source thread.
• google-oauth-domain-takeover — the Truffle Security domain-purchase flaw.
• oauth-token-theft — refresh-token replay and consent phishing.
• bitwarden — adjacent on the password-manager half of the alternative.
• long-lived-keys — refresh tokens as long-lived credentials.