GoKawiilReviving BrowserID in 2026
April 25, 2026
I'm building WKID ( W a k amoleguy's Id entity server), a BrowserID-style identity provider (IdP) for the bespoke apps I build for myself, my friends, and my family. Here's why I dusted off a 10-year-dead protocol to do it.
LLMs have made it easier than ever for developers to turn an idea into a working app. This lower barrier to entry means we are seeing an explosion of small, bespoke projects only meant for solo use, or for a few close friends or family. This software is by definition free-as-in-freedom, as the user is the developer and can modify it to their every whim and desire. I've hacked on a few of those projects myself, but one area that I've been struggling with is user management.
Even if an app is built to scratch my own itch, I often want to show-and-tell what I'm working on (so Tailnets and forward-auth gateways are out). I don't want to reinvent user management again and again for each service, and yet I also don't want my American Girl Doll shoe collector companion app to be dependent on the values of Google, Auth0, or some other corporation that could decide to suspend my account.
It turns out that BrowserID is a great fit for this:
It's federated based on email domains, and I control my own domains. That means nobody else has to be in the loop of my authentication flows.
It's private and censorship resistant by default. The IdP doesn't see what sites its users are logging into.
It uses email addresses as the identifier, so I don't have to separately collect email addresses and map them to passkeys, OIDC identifiers, etc.
It is very lightweight for relying parties to implement. There is no need to register each app with the IdP as you would for a centralized self-hosted server like Authentik.
... continue reading