Can We Make Identity Systems Simpler Again?

Look at the feature list of any major identity platform from ten years ago and compare it to today. Authentication, federation, tokens, sessions — all still there. But now there's also bot detection. IP reputation scoring. Rate limiting. Geo-blocking. Threat intelligence feeds. Fraud signals. CAPTCHA. Some vendors ship a WAF.

Every one of those was added for a defensible reason. A customer got hit by credential stuffing. A prospect asked for bot protection during evaluation. A competitor announced it. The feature shipped, the deal closed, the checklist grew.

And somewhere in that accumulation, identity platforms stopped being identity platforms and started becoming security platforms that happen to do authentication.

I want to argue that this was a mistake, that most of these responsibilities belong to layers that already exist and already do them better — and then I want to be honest about the specific places where that argument breaks down, because they're more interesting than the thesis.

The question that should get asked more

When a feature request arrives, the reflex is to ask can we build this? The better question is should this live here?

Take DDoS protection. Should an identity runtime absorb a volumetric attack? It's on the receiving end of one, certainly. But Cloudflare, Akamai, and AWS Shield operate globally distributed networks with terabits of absorption capacity, built by teams who do nothing else. An identity vendor building DDoS mitigation is building a worse version of a solved problem, with a fraction of the capacity, and then maintaining it forever.

Or IP reputation. Should every identity platform maintain a list of a hundred million malicious IPs? Keep it fresh? Handle the false positives when a residential ISP recycles an address? There are companies whose entire business is that dataset, and they're better at it than an identity team will ever be, because it's their product rather than their side quest.

Bot detection is the same story. Distinguishing automation from humans at scale is a specialized machine-learning problem with a dedicated industry — Turnstile, reCAPTCHA, Arkose — feeding on traffic volumes no single identity vendor sees.

In each case the honest answer to should this live here is no. Not because it isn't important, but because it's important enough that someone better positioned should be doing it.

The stack already exists

Modern architecture has layers, and each one specializes:

flowchart TB
    I["Internet"] --> E["CDN / DDoS edge"]
    E --> W["WAF · bot detection · IP reputation"]
    W --> G["API gateway · rate limits · geo policy · TLS"]
    G --> ID["Identity runtime"]
    ID --> A["Application"]

The edge handles traffic. The gateway handles requests. Identity handles trust. The application handles business.

That's a clean separation, and each layer is better at its job than the layers below it would be. The edge sees traffic patterns across millions of sites. The gateway sits in front of every API, not just the auth endpoints. Identity is the only layer that knows what an account is.

Kubernetes is the useful precedent here. It doesn't terminate your CDN, run your DNS, provide object storage, or replace your database. It could have tried — early container platforms did try, and mostly lost to the one that composed well. Kubernetes won by being excellent at scheduling and getting out of the way. Identity should learn the same lesson.

The dividing line that actually works

"Push security to the edge" is too crude to be useful as a rule, and taken literally it's wrong. Here's the version I think holds up:

If a decision can be made from the request alone, it belongs at the edge. If it requires knowing something about the account, it belongs in identity.

Run the examples through that test and the boundaries fall out cleanly.

A volumetric flood is visible in the request stream. No account knowledge required. Edge.

A request from an IP with a bad reputation — visible in the request. Edge.

Automation signals, TLS fingerprints, header anomalies, behavioral timing — all in the request. Edge.

Now the other side.

Forty failed logins against one account from forty different IPs in ten minutes. Every individual request looks completely normal at the edge — one attempt, clean IP, plausible headers. Only a system that knows the account can see the pattern. Identity.

A user who has authenticated from Germany for three years suddenly appearing from Brazil. The edge sees a request from Brazil, which is unremarkable. Identity has the history. Identity.

Password spraying — one attempt each against ten thousand accounts, distributed across a botnet. No IP is noisy. No account is noisy. Only a system with a view across accounts sees it. Identity.

This is the part that makes the naive version of the thesis wrong, and it's worth stating clearly: you cannot fully outsource abuse prevention to the network layer, because the most damaging identity attacks are specifically designed to be invisible there. Credential stuffing and password spraying work precisely by keeping every individual request beneath the threshold of anything the edge can measure.

So identity does need account-scoped rate limiting, anomaly detection across its own user base, and lockout logic. What it doesn't need is to reimplement IP reputation, run a bot ML pipeline, or absorb volumetric floods.

The rule isn't own less security. It's own the security that requires knowing who the account is, and consume everything else.

Consume signals, don't generate them

This reframes what an identity platform should be: a decision engine, not an inspection engine.

The edge and gateway do the inspecting. They produce signals — bot score, IP reputation, ASN classification, geo, device fingerprint. Identity consumes those signals, combines them with what only it knows (this account's history, its risk profile, what it's trying to access), and decides: allow, challenge, or deny.

flowchart LR
    subgraph Signals["Produced upstream"]
        B["Bot score: 95"]
        R["IP reputation: high risk"]
        G["Geo: unusual"]
    end
    subgraph Known["Known only to identity"]
        H["Account history"]
        D["Known devices"]
        V["Value of requested action"]
    end
    Signals --> Dec["Identity decision"]
    Known --> Dec
    Dec --> O["Allow · Step-up MFA · Deny"]

That's a genuinely better architecture than either extreme. The edge blocking on bot score alone produces false positives it can't contextualize — it doesn't know that this "suspicious" request is a known device belonging to an account that's been active for four years. Identity computing bot scores itself does a worse job than a specialist with a thousand times the traffic visibility.

Composition beats ownership in both directions.

The part nobody writes about: trusting the signal

Here's the engineering problem this architecture creates, and it's the reason "just read the header from the gateway" is harder than it sounds.

If your identity runtime makes decisions based on X-Bot-Score: 95 injected by the gateway, then anyone who can reach the identity runtime directly — bypassing the gateway — can set X-Bot-Score: 0 and skip the entire risk assessment. You've built a bypass and labeled it a feature.

This is a real, common vulnerability class in layered architectures and it has to be designed for explicitly:

Network path enforcement. The identity runtime accepts traffic only from the gateway — mutual TLS, a service mesh identity, or network policy that makes direct reachability impossible. If someone can curl your auth endpoint from the internet, your layered security model is decorative.

Strip and re-add. The gateway must strip any inbound signal headers from the client before setting its own. Otherwise a client simply sends the header itself and the gateway passes it through.

Sign the signals. Where the trust boundary is weaker, the upstream layer signs its assertions and identity verifies the signature. More overhead, but it removes the dependency on network topology being correct forever.

Fail closed on missing signals — carefully. If the bot score header is absent, is that a gateway misconfiguration or a bypass attempt? Treating "absent" as "benign" is the default in most implementations and it's the wrong default. Treating it as hostile breaks every deployment where the gateway isn't present.

Which leads directly to the biggest objection.

Where this thesis has real problems

Not everyone has an edge. If your architecture assumes Cloudflare in front, you've made your product undeployable for on-prem, air-gapped, and sovereign-cloud customers — which in enterprise identity is not a niche, it's a meaningful share of the market. A platform that's only secure when someone else's WAF is in front of it isn't secure; it's dependent.

The resolution isn't to build a WAF. It's to ship reasonable defaults that the edge can supersede: basic account-scoped rate limiting, simple abuse throttles, sane lockout behavior — enough that a bare deployment isn't defenseless, without pretending to be a security platform. Defaults, not a product line.

Boundaries create seams, and seams are where incidents live. When bot protection is owned by the network team and authentication by the platform team, who is accountable when credential stuffing succeeds? Both teams can correctly say their layer worked as configured. Clear ownership of components can produce unclear ownership of outcomes, and that's a real cost of composition that the elegant diagram doesn't show.

Debugging gets harder. A user is blocked. Which layer blocked them? Without correlated tracing across the edge, gateway, and identity runtime, this is a multi-team investigation for what would have been one log line in a monolith. Composition demands observability discipline that many organizations don't have.

None of these overturn the argument. They do mean "offload it to the edge" is an architecture, not a shrug — it requires trust boundaries, defaults, correlation IDs, and someone owning the end-to-end outcome.

What identity should own

Strip away the accretion and the remaining list is not small:

Authentication across passwords, MFA, passkeys, and social. Federation in both directions, with SAML and OIDC and everyone's slightly non-conformant IdP. Session lifecycle and the genuinely hard problem of logout. Token issuance, signing, and key rotation. Authorization policy. User lifecycle and provisioning. Account recovery, which is harder than everything else on this list. Audit that can reconstruct an incident.

That is more than enough for one platform to be excellent at. Every hour spent building a bot classifier is an hour not spent on the recovery flow that's actually going to be the source of your next breach.

And there's a compounding cost that's easy to miss: each absorbed responsibility isn't just built once. It's maintained, monitored, updated against evolving threats, supported, documented, and carried into every future architectural decision. A threat intelligence feed you ship is a threat intelligence feed you owe your customers accuracy on, forever.

The uncomfortable conclusion

The industry's incentives run directly against this. Feature checklists win evaluations. "We have built-in bot protection" is easier to sell than "we compose with the bot protection you already have," even when the second is the better architecture and the customer already pays for Cloudflare.

So platforms accumulate, because accumulation is what gets rewarded in a competitive bake-off. And the accumulated platform gets slower, harder to reason about, harder to upgrade, and harder to make claims about — all of which show up years after the deal closed, in operations rather than in sales.

Great platforms aren't defined by how many problems they solve. They're defined by how clearly they draw their boundaries. Identity platforms should authenticate users, establish trust, issue tokens, and evaluate policy. They shouldn't become WAFs, API gateways, fraud engines, CDNs, or SIEMs — not because those things don't matter, but because modern architecture already has excellent components for each of them, built by people who do only that.

The best identity architecture isn't the one that owns everything. It's the one that composes well and knows exactly which decisions it's uniquely positioned to make.