Google OAuth is broken (sort of)

Original Article ↗ Hacker News Discussion ↗

A recently highlighted Google OAuth behavior lets employees create separate Google accounts using email aliases (like [email protected]) that can persist outside the company’s control, potentially preserving access to third‑party apps such as Slack or Zoom even after off‑boarding. Commenters argue this stems less from a flaw in Google’s implementation and more from widespread misuses of OAuth/OIDC, especially treating email as a stable, trustworthy identifier instead of using proper subject IDs and verification flows. The exchange also raises concerns about the complexity of modern web authentication standards and whether bug bounty rewards like Google’s $1,337 payout meaningfully incentivize responsible disclosure.

Bug bounty value and Google’s response

  • Many see the $1337 payout as tokenistic given the potential impact and compare it unfavorably to higher payouts reported for similar issues elsewhere.
  • Others argue it’s generous for what they view as documented behavior or a “footgun,” not a classic vulnerability, and are surprised it was rewarded at all.
  • Some note payout delays (months between triage and reward) as typical for large companies, but feel the real issue is the low amount, not timing.

Who is actually at fault? Google vs integrators

  • One camp says the flaw lies primarily with third‑party apps (Slack, Zoom, etc.) that:
    • Use the email claim as the primary identifier.
    • Infer organization membership from email domains.
  • Another camp argues Google bears responsibility because:
    • Plus-address aliases and non‑org Google accounts share email routing but are invisible to Workspace admins.
    • Google could theoretically block new personal accounts on domains already claimed by Workspace customers or provide stronger controls.

Technical core of the issue

  • Google treats user+suffix@domain (and dot variants) as the same mailbox as user@domain, but allows separate Google accounts to be created with those addresses.
  • An employee can pre‑register a non‑org Google account using such an alias, then later use “Sign in with Google” to access corporate SaaS even after their official account is deprovisioned.
  • Impact depends on SaaS relying solely on the email claim for authorization; some commenters emphasize this is explicitly discouraged in OIDC docs.

Mitigations and best practices

  • Recommended patterns discussed:
    • Use iss + sub as the stable identity key, not email.
    • Never grant privileges purely based on email domain.
    • Require explicit provisioning or allowlists for corporate SaaS accounts.
    • Send independent email verification or use “magic link” + 2FA; critics note UX downsides and phishing risk.
    • Prefer SAML/SCIM or dedicated enterprise IdPs for B2B control.

Broader OAuth/OIDC and identity debates

  • Several participants describe delegated auth and OIDC as overly complex, poorly communicated, and prone to misconfiguration.
  • Disagreement over whether email should be treated as a primary identity:
    • Pro: globally understandable, widely used.
    • Con: unstable, reassignable, shared, and not unique across IdPs.
  • Some see the incident as emblematic of a messy web auth ecosystem rather than a single “Google OAuth is broken” moment.