Reviving BrowserID in 2026

I'm building WKID (Wakamoleguy's Identity 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.

For those unfamiliar, the BrowserID flow looks a lot like an OAuth flow:

1. A site displays a "Log In" button. This kicks off the BrowserID flow.
2. BrowserID prompts the user to enter their email address. Based on that address, they are routed to their IdP. They sign in.
3. The IdP provides a cryptographically signed assertion of the user's identity back to the BrowserID dialog, which signs and forwards it to the original site.
4. The site receives the verified email address, checks the signature, and creates a session.

If you're very familiar with BrowserID, you may be wondering whether WKID relies on 3rd party cookies, which are increasingly blocked across browsers. I will have to diverge from the spec to avoid this, but I have a plan. :-)

BrowserID failed in 2016, but WKID won't

Mozilla had a big chicken-and-egg problem with BrowserID. Identity providers were not incentivized to join the federation unless enough relying parties were using it, and relying parties didn't want to use it unless their users' identity providers supported it. Mozilla tried to solve this by hosting persona.org as a fallback IdP that could verify any email address, but there still wasn't enough traction to take off. I won't have that problem, because I am moving the goalposts.

I'm not trying to win the IdP market globally. WKID is itself a bespoke app for my own use. If I only have a handful of my own hobby services using it, and only for one user, that's still a win. If somebody else finds it useful and adds it for their projects, we get federation as a bonus. For that reason, and because actually sending email is a whole can of worms (deliverability, abuse, reputation), I'm not planning on hosting fallback IdP functionality at all!

This means that users won't be able to use my apps unless their email domain provider supports WKID. And the big providers (gmail.com, outlook.com, yahoo.com, icloud.com) will never be supported. That would be an insane assumption for any business, but remember these are bespoke apps. My users are me and my family who have emails on my domain.

Where WKID stands today

WKID is still in development and not quite ready to share. End-to-end flows are functional and tested, but it needs some styling polish, documentation cleanup, and simpler self-hosting instructions.

My qualifications for working on this are mainly that I have had an affinity for BrowserID since the days when I worked on unified communications apps that relied on email, XMPP, and SIP addresses (which all follow the user@domain format), plus a decade or two of building web SaaS.

If you have advice from working on authentication services, or if you'd want to try WKID with your own projects, @ me.

Cheers!