OAuth Account Linking Abuse

Account linking is where OAuth meets the app's own account system, and it goes wrong when the app merges identities on an email claim it never verified. The result is account takeover, often staged before the victim even signs up. This page covers the attack. Practice on a free live target.

The linking flow

Many apps let a user attach a social identity to an existing account: "Link your Google account" in settings, or "We found an account with this email, want to connect it?" at social-login time. The linking decision usually comes down to matching the email the provider asserts against an existing account's email.

The trust gap

The email in an OIDC assertion proves the provider knows that email. It does not prove the person owns the matching account on this app. When the app links on the email string alone, without verifying control of the existing account, two different ownership facts get conflated, and whoever controls either side wins.

Pre-account-takeover: the classic sequence

1. The attacker registers a local account on the app using the victim's email, [email protected]. Many apps allow signup without verifying the email, so this succeeds.
2. The attacker sets a password they know and waits.
3. Later the victim arrives and clicks "Log in with Google." Google asserts [email protected].
4. The app sees an existing local account with that email and links the Google identity to it, without checking the victim controls that local account.
5. The victim now logs in happily, but the attacker still holds the password they set in step 2, so both parties share the account. The attacker logs in later and reads everything the victim added.

attacker: POST /signup  [email protected]  password=attacker_knows   (no email verification)
victim:   "Log in with Google" -> provider asserts [email protected]
app:      links Google identity to the pre-existing local account  (no ownership check)
result:   one account, two owners, attacker was first

The reverse direction

It also runs the other way, though this direction is harder: the attacker must control a provider identity that asserts the victim's email, which needs either a rogue IdP the app wrongly trusts or a provider that does not enforce email_verified. If they have that and the app merges on the email claim, the attacker's social login opens the victim's account. Both directions share one root cause: linking on an unverified email claim.

Step: test it

1. Does signup verify the email before creating the account?  (if not, pre-stage is possible)
2. Does linking match on email alone?                          (request the flow, watch the merge)
3. Does linking require proving control of the existing account first?  (log in / email confirm)

If signup does not verify email and linking matches on email without an ownership check, the flow is vulnerable.

Fixing it

• Verify email ownership before linking, by requiring the user to log into the existing account or confirm a link sent to that address.
• Verify email at signup, so an attacker cannot pre-register a local account on someone else's address.
• Key accounts on iss plus sub, not on a mutable email claim, so a matching email never silently merges identities.

Full guidance is in preventing OAuth attacks. This is an account-takeover path alongside the ones in authentication. Next, phish a token in device flow abuse, or try account linking on a free lab.