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

Original Article ↗ Hacker News Discussion ↗

A security researcher argues that Google’s “Sign in with Google” OAuth flow can let attackers hijack accounts at third‑party services by buying expired domains once used by defunct startups, then recreating matching Workspace users. Commenters counter that this risk largely stems from long‑known weaknesses in email/domain‑based identity and from relying parties ignoring the immutable `sub` identifier in favor of email or domain (`hd`) claims, though some note reports that `sub` itself occasionally changes in practice. The thread broadens into whether this is truly a Google/OAuth flaw or a governance problem around domain expiration, data retention, and how SaaS providers implement SSO and account recovery.

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.