Google OAuth: identity drift risk after Gmail rename

Hey. Heads up on something I found while looking into the impact of Google's Gmail rename feature (shipped 31 March 2026).

What changed

Google now lets users change their Gmail address. After rename plus token revocation the OmniAuth callback receives the new email. Google's own developer docs acknowledge this produces duplicate accounts in downstream apps.

What I found

In clover.rb the OmniAuth flow resolves accounts using email. After a Gmail rename, if the old email no longer matches the account record, the flow either creates a new account or fails to authenticate. For a cloud infrastructure platform this has real consequences. A user could lose access to running VMs and resources tied to their old account.

I noticed you have locked domain logic and provider-aware validation which is smart. That protects managed enterprise accounts. The exposure is primarily for users authenticating with personal @gmail.com accounts through Google OAuth.

My recommendation

I'd recommend using the OmniAuth uid (which maps to Google's sub claim) as the primary account lookup key. Email stays as the display and communication field. This way a rename doesn't break the identity chain.

For reference, cal.com (41K stars) already does this. They use token.sub as the primary key. Email handles rate limiting and nothing else. Good pattern to follow.

Context

I found this pattern in 124 public repos during a code audit across four OAuth ecosystems. Full writeup: Google Externalised the Cost of Renaming Gmail

I also built authdrift, a Semgrep scanner that detects the email-keying pattern. Might be useful for checking other auth paths in Ubicloud.

Let me know if more detail on the specific code paths would help. Happy to dig in.