Edge Identity Fabric v2
Projects

Edge Identity Fabric v2

Identity is the last great centralized monolith in most modern architectures. Even if your application is globally distributed, highly available, and running serverless at the edge, your authentication and authorization traffic almost always bottlenecks back to a centralized Identity Provider (IdP) region.

This introduces unavoidable latency, hard dependencies, and data sovereignty headaches.

Edge Identity Fabric v2
MultiTenancy + Programmable Identity hooks and limits

For the past few months, I’ve been ideating on a solution: an Edge Identity Fabric. The goal is to move the core responsibilities of an IdP—multi-tenancy, custom logic execution, threat protection, and data pinning—entirely to the network edge.

Today, I’m thrilled to share a small update to the Edge Identity Fabric PoC. We have moved beyond theory and built a dynamic, programmable infrastructure that demonstrates how the edge can inherently solve the complex problems of modern IAM.

Here is a deep dive into the new architecture and the “killer features” we’ve implemented.

The Architecture: Multi-Tenancy via V8 Isolates

The biggest challenge in building an IdP at the edge is multi-tenancy. You cannot have one customer’s custom auth code affecting another’s. We needed strict execution isolation.

To solve this, we refactored the core fabric to utilize Cloudflare’s Dispatcher pattern ([[dispatch_namespaces]]). Here is the new request flow:

  1. A user requests their SSO login page (e.g., tenant-a.auth.edge).
  2. The request hits the main Edge Identity Fabric Worker.
  3. We refactored to the tenant ID from the hostname or route parameter.
  4. The Worker utilizes env.tenants.get(tenantId).fetch(request) to instantly route the request to that specific tenant’s dedicated V8 edge isolate.

This gives us true multi-tenancy at the metal. Tenant A’s auth hooks, user data context, and configurations are entirely isolated from Tenant B, yet they all run on the same global network infrastructure without cold starts.

The Control Plane: On-Demand Edge Provisioning (/wfp)

To make this PoC usable by the public, we couldn’t rely on manual code uploads via the Cloudflare API for every new tester. We needed a control plane.

We built a sleek dispatcher dashboard at the /wfp endpoint. This allows users to set up a dummy organization and see the fabric in action immediately:

  • Tenant Registration: Users enter a mock company name, a unique tenantId, and preset user emails.
  • Edge DB Provisioning: Upon submitting, a POST to /wfp/provision automatically provisions these users seamlessly into an Edge D1 SQL Database associated specifically with that tenant environment.
  • Auto-Routing: Once provisioned, the user is instantly directed to their newly created, mocked infrastructure endpoint to experience the login flow.

Edge-Native Killer Integrations

The crowning achievement of this update is the visual simulation of three prioritized features. These are not static mockups; they are real-time execution telemetry.

1. Zero-Latency Custom Auth Hooks Centralized IdPs offer “actions” or “lambdas” to inject custom logic during the auth flow (e.g., “check if user is in Salesforce before allowing login”). These introduce massive latency.

In our provisioning UI, you can enter a custom JavaScript snippet. The Edge node evaluates that logic immediately prior to processing authentication. Because it runs in the same edge isolate as the auth flow, the latency is negligible.

2. Network-Level Threat Protection Why make an API trip to a third-party bot protection service when you are already running on the world’s leading network security platform?

When provisioning a tenant, you can toggle Cloudflare Turnstile. The resulting SSO screen natively integrates and enforces Turnstile Bot Protection at the edge network level, stopping some bots before they even attempt authentication, with zero additional round trips.

3. Jurisdictional Data Sovereignty For global enterprises, GDPR and emerging data residency laws are nightmares. They need guarantees that US user data stays in the US, and EU data stays in the EU. Centralized IdPs struggle to guarantee this during processing without separate clouds.

Our provisioning UI now explicitly binds to a jurisdiction drop-down. In the SSO GUI, we render a telemetry badge pinning the authentication execution space. If you select EU, the network guarantees the V8 isolate executes within EU boundaries, ensuring no external geographic transmission of processing data.

The Future is Edge-Native

Centralized identity and traditional identity is quickly showing its age in the era of agentic and non-human identities. By using the unique primitives offered by the network edge, developers can build an identity fabric that is faster, more secure, and more compliant than anything running in a centralized cloud.

This PoC is just the beginning. The shift from centralized pillars to a distributed edge identity fabric is inevitable. I’m just playing with the building blocks.

What should I explore next?

Learn More

Technologist Poet. Dabbler Extraordinaire.