Google’s OAuth login doesn’t protect against purchasing a failed startup domain

Original Article ↗ Hacker News Discussion ↗

What’s being claimed as the vulnerability

  • If a startup’s Google Workspace domain lapses and a new owner re-registers it, the new owner can create matching emails and use “Sign in with Google” to access third‑party SaaS accounts previously linked to that domain.
  • Impact examples discussed: Slack, HR/payroll systems, GitHub accounts, interview tools, even financial/benefits portals that allowed corporate SSO.

Is this really a Google/OAuth flaw?

  • One camp: this is fundamentally a domain/email‑based identity problem; any auth (including plain email+password resets) breaks once a domain is re‑owned.
  • Others: OAuth/SSO is supposed to improve on raw email-based trust; if Google can see that a Workspace/org is completely different, it should not silently attest that these are the “same” identities.
  • Some view Google’s original classification as “fraud/abuse” (not OAuth) as technically correct but think Google still has a responsibility to mitigate.

sub, email, and hd claims

  • Specs and Google docs say sub is the unique, stable user ID and should be used to identify users; email is for contact, hd is the hosted domain.
  • Critical dispute: an anonymous “0.04% of logins have changing sub” claim.
    • Some practitioners report never seeing this; others report sub changing on domain changes, company acquisitions, or employees being deleted and re‑created.
    • If sub really changes for the same human, SPs either break logins or ignore sub and fall back to email/hd, which re‑introduces the vuln.
  • Several commenters argue the real bug (if any) is sub instability; others suspect misprovisioning or misinterpretation rather than a systemic Google issue.

Public vs internal Google OAuth and other IdPs

  • Distinction:
    • Public Google OAuth client: allows any Google account (Gmail or any Workspace) to log in; many SaaS apps use this plus hd/email domain filtering.
    • Internal OAuth or SAML: bound to a specific Workspace/tenant via keys/certs; new domain owners can’t reuse the integration.
  • Some say using public OAuth for “corporate SSO” is a misuse; others note Google’s own docs encourage checking hd to restrict by domain.
  • Microsoft/Entra is cited as having stronger org/user GUID claims that distinguish tenants cleanly.

Domain lifecycle and messy shutdowns

  • Many comments push back on the article’s “millions of accounts” framing but agree failed companies often:
    • Let domains lapse or can’t transfer them.
    • Leave SaaS and SSO integrations running.
    • Don’t reliably delete third‑party data.
  • Anecdotes: buying lapsed domains exposes old email flows, lets attackers reset social accounts, or even regain access to old Google Apps data (in older setups).

Mitigations and proposed fixes

  • For SPs:
    • Treat sub as the primary key; never treat email/domain as identity.
    • If sub changes for an existing email, trigger manual/secondary verification or create a new account, not silent reassociation.
    • Optionally use SAML or internal OAuth clients tied to a specific Workspace/tenant, not the public Google OAuth endpoint.
  • For IdPs / protocol design:
    • Add an immutable org/workspace identifier separate from hd so SPs can detect that “example.com (Workspace A)” ≠ “example.com (Workspace B)”.
    • Some point to Microsoft’s multiple GUID claims as a model.
  • For companies:
    • Don’t let important domains expire; some suggest renewing for many years or using catch‑all inboxes to find stragglers.
    • Avoid using corporate emails as the only identifier for personal or long‑lived accounts (e.g., retirement plans).

Unclear / disputed points

  • Whether sub actually changes for the same underlying Google account at the reported rate is heavily disputed and not independently evidenced in the thread.
  • It’s unclear what exactly Google agreed to “fix” when they reopened the bug and paid a bounty; no technical details are provided.