One amazing thing about extra free-time is the ability to dabble. And dabbling plus the power of vibe coding can yield some fascinating results when it comes to building MVPs and PoCs.
After my stint in the identity security space, I kept asking myself why there wasn’t a better solution for developers to simply ‘build their own’ IdP – particularly in the rising world of agentic and non-human identities where access controls didn’t always equate directly with headcount. Was it simply the lack of infrastructure? The complexity or scale of the problem?
Additionally, a lot of the problems in the identity space seemed to be caused by the legacy approach to identity, which was generally a solved problem on the network idea (short-lived, Just-in-time access with variable TTLs (time-to-live)).
So, with that in mind, I found some giant shoulders to start from (Workers-OIDC Circa 2021) and decided to join a few other folks on Github with edge identity experiments. At this stage, I just wanted a simple PoC for a scalable, low-latency, multi-tenant OIDC Identity Provider (IdP) built entirely on Cloudflare Workers, D1, and Durable Objects.
Check out a demo page here: https://eif-main-dispatcher.dan-hollinger.workers.dev
(Note: I’ll open up the Github repo once I know its been scrubbed for IDs and keys. My code-fu and agent-assisted code-fi is still pretty rusty, and I’d rather be safe than exploited.)
The EIF Vision: Eliminate Latency from the Login and Scale Identity for the Future
The core idea behind EIF is to move the identity logic (the OIDC provider) and the identity data (user credentials) from a central datastore to the closest edge node. To test this, we built a PoC designed to achieve sub-30ms response times for authentication requests, regardless of the user’s location.
To visualize how we achieved this performance while maintaining security and tenant isolation, consider the architectural overview below:
As the diagram shows, the request flow is entirely decentralized:
- An End-User (Client) makes an OIDC Authorization Request.
- This request hits the Cloudflare Edge Node, where the Dispatcher Worker (Gateway) immediately takes over. (Note – On the roadmap – I didn’t have Dispatcher entitlement when I got going.)
- Instead of processing the logic itself, the Dispatcher accesses the “eif-identity-db (Cloudflare D1)” to look up the specific tenant configuration.
- (vNext) Crucially, it would then use the dispatch-namespace primitive to forward the request to an isolated User Worker. This worker is tenant-specific, meaning it can run custom branding, hooks, or unique security policies without compromising other users on the platform.
- This isolated worker performs the actual AuthN/AuthZ Logic (Passkey/WebAuthn), utilizing the Web Crypto API for high-performance RS256 signing of JWTs.
- For transaction consistency (e.g., ensuring an authorization code isn’t reused), it leverages a dedicated “Transaction Consistency (Durable Object)” (AuthSessionDO).
By co-locating the compute and the data (D1) at the edge, we effectively eliminate the “speed limit” inherent in centralized identity systems like Okta or Entra, providing a better end-user experience for both latency and scale.
Vibe Experimenting: Speed-to-Environment
One of the most remarkable outcomes of this project was the ease of standing up the development environment. Moving from idea to a working dispatcher model took hours.
The Cloudflare ecosystem provides an incredibly low barrier to entry for complex, distributed systems. Using Wrangler, we were able to configure and deploy a D1 SQL database, a Durable Object for session state, and the main gateway worker with just a few lines of configuration in our wrangler.toml.
This speed-to-environment allowed us to focus our energy on the core differentiator: the OIDC logic and the Passkey-native authentication flow, rather than the tedious infrastructure plumbing often required for multi-tenant applications.
Outcomes and the Road Ahead: What I want to test next
This PoC is really about showcasing an N=1 model, but I think the real value is potentially in an Custom-Idp-as-a-service built on an edge network. A one-click deploy factory allowing small devs and SMBs to craft their own high-performance IDP without the complexity or cost of traditional identity overhead.
- One with reduced latency
- One with reduced cost
- One that can scale with agents and non-human identities alike
- And one that potentially steals from network-authorization paradigms that help prevent identity debt from building up in the first place.
Next steps:
- Tenant Handoff Security: Confirming that the Dynamic Dispatcher (dispatch-namespace) reliably and securely isolates tenant-specific logic, allowing developers to upload their own “Auth0 Action”-style hooks while ensuring that the “Main IdP” gateway remains secure.
On a different note, what should I vibe dabble in next?
