OAuth Signup Fraud: Detecting Fake Google & Apple Sign-Ins

Most product teams treat "Sign in with Google" as a trust signal. The reasoning: Google verified the email, so the user is real. In 2026, that reasoning is broken.

Here's how much it costs to buy a batch of aged, phone-verified Google accounts: about $0.40 each, bulk-purchased from Telegram sellers. Microsoft accounts are $0.20. Apple IDs (which require paid device attestation) run $2–$5. For a fraudster running a bonus-abuse farm or a SaaS trial scraper, this is an operating cost, not a barrier.

How OAuth signup fraud works in practice

Fraudsters target OAuth signups specifically because most platforms skip their usual fraud checks when the user authenticates with Google or Apple. The typical flow:

1. Buy 500 aged Google accounts ($200 total). Aged = created 6+ months ago, with login history and a verified phone.
2. Spin up a Kameleo profile per account — unique canvas, WebGL, timezone, user agent.
3. Route each session through a different residential proxy endpoint.
4. Hit the target signup flow, complete OAuth, redeem the signup bonus / trial / free credits.
5. Repeat 500 times. Cash out.

Because the user hit Google's consent screen and logged in successfully, every signal your application sees looks legitimate: verified email, established account history, no password to crack. Your fraud model never gets invoked.

What signals are actually reliable

Email verification tells you almost nothing about fraud intent. The high-signal checks for OAuth signups are all device- and network-layer:

• Residential proxy flag — fraudsters need proxies to rotate IPs across 500 signups. Detecting the proxy catches the entire batch.
• Antidetect-browser tampering — aged Google accounts are worthless unless the fraudster can rotate browser fingerprints per session. That rotation is what tampering detection catches.
• Visitor ID persistence — a single device completing 12 OAuth signups in a day is diagnostic. Verified email, verified device, 12 accounts — that's the fraud pattern in one line.
• Session age vs account age — a fresh session on a fresh device claiming an aged Google account is suspicious. Real users' session devices usually correlate with their account history.

A 15-line integration

The Maskbreak SDK issues a session token on page load. On OAuth callback, you pass both the OAuth ID token and the Maskbreak token to your server:

// /auth/google callback handler
app.post('/auth/google', async (req, res) => {
  const { idToken, monocle } = req.body;

  // 1. Verify Google ID token as usual
  const ticket = await googleClient.verifyIdToken({ idToken });
  const email = ticket.getPayload().email;

  // 2. Ask Maskbreak what this session looks like
  const sentinel = await fetch('https://maskbreak.com/v1/evaluate', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer sk_live_YOUR_KEY',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ token: monocle })
  }).then(r => r.json());

  // 3. Count prior accounts by the same device
  const priorCount = await db.query(
    'SELECT COUNT(*) FROM users WHERE visitor_id = ?',
    [sentinel.deviceIntel?.visitorId]
  );

  if (sentinel.isSuspicious || priorCount > 3) {
    return res.status(403).json({ error: 'signup_blocked' });
  }

  // Safe — create account
  await createUser(email, sentinel.deviceIntel?.visitorId);
});

Apple Sign-In: same problem, slightly rarer

Apple IDs are harder (and more expensive) to farm because of the $99 developer entry for reliable bulk generation. But they're not immune — particularly because Apple's "hide my email" feature generates unique relay addresses, making email-based deduplication useless. The same device-layer checks apply.

What about magic-link / passwordless?

Same problem, same solution. Magic link flows let you verify "someone controls this email," but they give you zero information about whether the device / network context is legitimate. Maskbreak runs on the client page regardless of the auth method, so you can gate any email-verification flow the same way.

Dashboard insight: catching the farm

The operational signal you want in your dashboard: accounts per visitor ID. Run this weekly:

SELECT visitor_id, COUNT(*) as accounts
FROM users
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY visitor_id
HAVING COUNT(*) > 3
ORDER BY accounts DESC;

Any visitor ID with more than ~3 accounts in a week is almost certainly a farm. Ban the visitor ID (not the email) and every future signup from that device automatically fails, regardless of which Google account they use next.

Getting started

Free tier at maskbreak.com/signup includes the visitor ID signal. Drop it in next to your OAuth callback and you'll start seeing your signup fraud pattern within 24 hours.

Update: agent-driven signups

A pattern worth adding: signups completed by a browser-driven agent on a real person's behalf. The OAuth handshake is genuine, the Google or Apple account is genuine, and the human did ask for the outcome — but the flow is automated end to end, so every behavioural signal reads like a bot.

Blanket-blocking automation at this step therefore rejects real customers. The workable pattern is the one this post already recommends for other cases: treat the provider assertion as evidence of identity, then scale scrutiny to what the new account can immediately do. An account that can only read is cheap to grant; one that can immediately claim a referral credit is not. The decision guide sets out where to put the gate.