If you’ve ever had to get authentication working just well enough to ship, this will probably feel familiar: at some point you shipped login and moved on. Maybe OAuth, maybe a JWT flow, maybe something your team built and only two people now understand. The users authenticated, the sessions resolved, the logs looked clean. It worked.

Then, somewhere down the line, you noticed something was off. Signups spiking in a pattern that didn't match any campaign. Engagement metrics that looked great but converted to nothing. Reward pools draining faster than real users could account for. You pulled the thread and found accounts that looked like users but weren't.

The system didn't break. That's what makes it hard to talk about.

Login was never a trust model

The assumption baked into most auth stacks is that an account represents a person. It's a reasonable shortcut — someone had to create it, verify an email, maybe pass a CAPTCHA. For most applications, for most of their history, that held.

But login doesn't verify a person. It verifies a credential. An email address. A password hash. An OAuth token. These are proxies for identity, not identity itself. Once a system rewards accounts — with access, money, reputation, influence — the gap between "account" and "person" is a gap worth exploiting.

That's not a flaw in your implementation. It's a flaw in the model.

What your auth stack actually knows

At login, your stack knows the user has access to an email address or an OAuth provider. After a few sessions, it knows their IP range, device fingerprint, usage patterns. It builds a behavioural profile, and if the profile matches what "normal" looks like, it extends trust.

What you've built is an inference engine. Not a verification system.

That's fine when the stakes are low and faking "normal" is expensive. A solo operator with a handful of fake accounts probably isn't worth building a more rigorous check for. But inference breaks when the incentive to appear normal goes up, because the cost to do so comes down. Automated account creation is cheap. CAPTCHA-solving services work. Behavioural patterns can be warmed. History can be manufactured.

When bots clear all your checks, it's not because your checks were weak. It's because they were answering the wrong question.

The question you're not asking

What most of these problems actually need answered isn't "does this account have valid credentials?" It's closer to:

• Is this a real, unique person?

• Have they already claimed this reward under a different account?

• Are the 200 signups today 200 different humans, or one person with a script?

Login doesn't answer those. It was never meant to. An account is a relationship between a person and a service — it doesn't contain any ground truth about who's behind it. Most stacks never ask for that ground truth, partly because historically there was no clean way to get it without putting users through something that felt less like a signup and more like a background check.

When it gets expensive

The most visible version of this problem is the one that costs money directly: airdrops, reward programs, referral schemes, subsidised tiers. Build one and you'll find out fast that "one account = one person" doesn't hold under any real economic pressure.

The slower version is harder to catch. Engagement metrics padded by bots. A/B tests contaminated by non-human traffic. Moderation decisions made on account age and history, applied to accounts manufactured to look aged and historical. Feed algorithms that learned to rank what bot networks found easy to game.

The logs stay clean. The gap between what the system thinks is happening and what is actually happening grows slowly enough that you don't notice until something forces you to look — and by then it's been there for a while.

The patch problem

The standard response is operational: better CAPTCHAs, rate limiting, tighter behavioural signals, faster fraud detection. These are worth doing. They raise the cost of an attack.

They don't fix the assumption.

The assumption — that you can determine whether someone is a real person from signals and proxies, without ever actually verifying it — is architectural. It's in the original decision to make the account the unit of trust instead of the person.

Patching operationally adds complexity without resolving the gap. More checks, harder to reason about, false positive rate creeping up, all to approximate an answer your system was never designed to give directly.

There's a different design — one where "is this a real, unique person?" has a verified answer at the point of access, not inferred after the fact. Where the account is just a record, and the trust comes from somewhere else.

That approach exists. It's not common yet, partly because most auth decisions got made before the problem was this visible, and partly because "verify that users are actual humans" sounds obvious until you try to spec it. The question is whether you want to keep building on inference until it breaks badly enough to force the issue, or get ahead of it.

Most teams wait for the forcing event.