# Google OAuth is broken (sort of)

Google OAuth email claim trusts non-Gmail accounts with plus-addressed corporate emails, letting off-boarded employees keep Slack/Zoom access indefinitely.

- Payout: $1,337
- Severity: medium
- Program: Google, Zoom, Slack
- Credited: Dylan Ayrey
- Disclosed: 2023-12-15
- Write-up quality: 7/10
- Original: https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/
- Library page: https://bugbountylibrary.com/r/blog%3Atrufflesecurity-com-blog-google-oauth-is-broken-sort-of
- Tags: domain:web impact:internal-access impact:privesc kind:bounty platform:blog sev:medium tech:oauth tech:oidc technique:recon vuln:access-control vuln:auth-bypass

**Target:** Google OIDC email claim used by SaaS providers (Slack, Zoom)
**Root cause:** Google allows creating non-Gmail Google accounts using arbitrary existing email addresses, including plus-addressed corporate emails; the OIDC email claim then reflects that address, and service providers authorize on the email domain rather than org membership (HD claim).
**Steps:**
1. Create a Google account using a non-Gmail address, e.g. `[email protected]` (plus-addressed corporate email that forwards to the real inbox).
2. Complete Google account creation via the forwarded verification email.
3. Log into Slack/Zoom via 'Sign in with Google' using this account; the OIDC email claim is `[email protected]`.
4. Provider parses the domain and grants access; the account is not a member of the Google Workspace org, so it never appears in admin user lists and cannot be off-boarded.
**How found:** After seeing Descope's Microsoft OAuth email-claim issue, the researcher checked Google's OIDC docs and found Google itself warns against using email as an identifier. Testing showed non-Gmail Google accounts can be created with arbitrary addresses, and two accounts can emit the same email claim after editing.
**Exploitation:** A departing employee pre-creates a non-Gmail Google account with a plus-addressed corporate email before off-boarding. After removal from the Google org, the account persists and continues to authenticate to Slack/Zoom via Google OAuth, since providers authorize on the email domain claim.
**Escalation:** With no initial access, an attacker can create a support ticket (e.g. Zendesk) to obtain a support email address on the target domain, create a Google account with it, view the ticket to finish account creation, then OAuth into services using the support address.
**Insight:** When auditing OIDC integrations, check whether the provider authorizes on the email claim's domain rather than an org-membership claim (HD); test whether the IdP lets you mint accounts with plus-addressed or alias addresses on the target domain that live outside the org's admin control.