Your product lets someone sign in with Google, or with their existing email and password, and treats both as the same account whenever the email addresses match. This is genuinely convenient: a user who signed up with a password can later click "continue with Google" and land in the same account rather than creating a duplicate.
It is also a decision to trust a claim, the email address presented by an identity provider, as sufficient proof that two different authentication events belong to the same person. That trust is usually well placed. The specific case where it is not is worth understanding precisely, because it produces one of the cleaner account takeover paths available against a modern authentication system.
The linking decision, and what it actually verifies
The common implementation: a user authenticates via an OAuth provider, the provider returns a verified email claim, and your system looks up an existing account with that email. If one exists, it links the new authentication method to it. If not, it creates a new account.
That is correct when the identity provider genuinely verified the email and when every identity provider you accept treats email verification the same way. Both assumptions can fail.
Where email is not actually verified
Not every OAuth provider verifies email by default, and some verify it for the primary address on the account while allowing secondary, unverified addresses to be added and, depending on configuration, presented in a token's claims. A system that reads the email claim without checking the corresponding verification flag is trusting an assertion the provider itself did not stand behind.
Providers differ in what "verified" means and how reliably they enforce it. Some smaller or self-hosted identity providers make email verification optional or configurable by the operator running that instance, which matters when you accept a broad set of providers rather than one or two you have specifically reviewed.
A user can sometimes register an email with one provider before its true owner ever creates an account anywhere. If your system creates an account on first sign-in and links future logins by email match, an attacker who registers victim@example.com on a provider with lax verification, before the real victim ever uses that provider, can potentially claim the linking slot for that address ahead of them.
The takeover sequence
An attacker identifies a target's email address, which is usually not difficult, since it is frequently the same address used across many services or simply their known work or personal address. The attacker signs up with an identity provider using that email, on a provider or in a configuration where verification is weak or the provider does not confirm ownership as strictly as your system assumes. Your application receives an OAuth callback with that email in the claims, finds a matching existing account, if the victim already has one, or is the first to create the account, if the victim does not yet have one, and links the attacker's OAuth identity to it.
From that point, the attacker has a standing, legitimate-looking authentication method into an account that either already belonged to someone else or is a newly created account waiting to be claimed by them.
What to actually check
Read the email verification claim, not just the email claim, from every provider you accept, and refuse to link, or require an additional confirmation step, when the provider does not assert verification. This is one field to check and it closes the largest version of the gap.
Send a confirmation to the existing account's registered email before completing a link to it, rather than linking silently on the strength of a matching address alone. This adds a step to a flow designed to remove friction, and it is the single most reliable check available, because it verifies ownership through a channel your system controls rather than trusting a third party's assertion.
Never auto-link based on an unverified claim, full stop, treating an unverified email match as grounds to create a new, unlinked account instead, with its own explicit path to merge accounts later if the user requests it and can prove ownership of both.
Treat every identity provider you integrate as carrying its own trust level, and configure accordingly. A large, well-known identity provider with strict verification deserves different treatment than a generic OpenID Connect provider you added to support one customer's request, and collapsing them into identical linking logic means your weakest accepted provider determines the security of the whole feature.
Notify the account when a new authentication method is linked, the same discipline as notifying on any other security-relevant change, so a legitimate account holder who did not initiate a link finds out promptly rather than discovering it only when something goes wrong.
Check yours
Read your account-linking code directly and answer one question: does it check a verification flag on the incoming claim, or only the email address itself. If it is the address alone, that is the finding, and it applies to every identity provider your system currently accepts, not just the one you happen to test with most often.
Then test it: register an account with your product using a normal email and password, and separately create an account with an identity provider you support using that same email, checking specifically whether that provider requires you to prove ownership of the address before issuing a token containing it.
The concession
Requiring a confirmation step before every link adds friction to a feature whose entire value proposition is removing friction, and for products where the identity providers offered are limited to a small number of well-known, strictly verifying options, the residual risk of trusting the email claim directly is genuinely low. Not every product needs the full confirmation flow.
The proportionate response scales with how many providers you accept and how well you actually know each one's verification behaviour. A product supporting sign-in with one major provider, correctly checked for a verified claim, is in a different position than one accepting a dozen OpenID Connect providers of varying rigor with identical linking logic applied uniformly across all of them.
The implication
Account linking by email match is a decision to extend trust from your own authentication system to whatever an external identity provider asserts, and that assertion is only as strong as the weakest provider you accept and the specific claim you choose to read from it.
Check the verification flag, not just the address, on every provider your product supports. It is one field, and it is the entire difference between a convenience feature and an open door.
