Here's my specific complaint about identity on the internet: every login is a shared secret, and every shared secret leaks.
A password is a secret you share with every site you use. A magic link is a secret that sits in your inbox, so your email account quietly becomes the master key to everything. "Sign in with Google" is convenient, and it hands one company a map of everywhere you go. And every one of those approaches leaves the site owner holding something worth stealing, one breach away from a very bad week.
I've built a lot of authentication. Earlier this year I shipped AuthnzNet, an OAuth 2.0 and OpenID Connect server you can run as a single dotnet tool. Building that made the problem sharper for me, not smaller. The protocols are good. What sits underneath them, an account somewhere with a secret attached, is the weak part.
What About Passkeys?
Passkeys are the closest the industry has come, and I want to be fair to them. They got the cryptography right. A key pair per site, the private key never leaves your device, nothing to phish.
And then they handed the keys to the same three companies to sync. Your passkeys live in Apple's, Google's, or Microsoft's cloud. That's a reasonable trade for a lot of people. But it's still an account, at a company, that someone can lock you out of.
I think the honest answer has been sitting in your pocket the whole time.
The Phone Is the Identity
Identizen is identity without the account. Your phone holds a cryptographic identity. Your biometric unlocks it. The site you're logging into receives a standard OpenID Connect token. No password, no email, and no identity-provider account to create, reset, or breach.
Under the hood:
- A 256-bit seed is generated on your phone and shown to you once as 24 recovery words. Everything else is derived from it.
- Every site gets its own Ed25519 key, derived from that seed and the site's host. Two sites can't compare notes and figure out they have the same user, because to them, you aren't the same user.
- Sites never get your email or phone number. They get a per-site subject ID, and that's it.
- The site's origin is inside the challenge your phone signs, so a lookalike domain can't relay your login. And a two-digit match code on screen stops push-bombing, where an attacker spams approval requests hoping you'll tap one to make them stop.
Standard on the Outside
This is the design decision I care about most. The new cryptography stays behind a completely ordinary OpenID Connect boundary. Your app does normal OIDC with PKCE, the same flow your framework already supports. You don't install an Identizen SDK. You don't learn a new protocol. If your stack can do "Sign in with Google," it can do Identizen.
My rule for the team, written right on the about page: if integration takes more than five minutes, it's a bug.
You can use it two ways. As the primary login for your site, replacing passwords entirely. Or as push-to-phone MFA layered on top of the login you already have, which is a much easier conversation to have with an existing product team.
There's also signed authorization. Your backend can send the exact text of an action, like "Approve wire transfer of
The Index Is a Phonebook, Not a Vault
If there are no accounts, what does Identizen actually run? An index. It maps a handle like name@index.example.com to the phone that currently holds that identity, and it brokers the live login session. That's all.
Nothing at Identizen can sign in as you. There's no password database, no secret to steal. The index is designed so that if its whole database leaked tomorrow, nobody could log in as anybody.
And you don't have to use mine. The platform is open source under Apache 2.0. The index runs on Cloudflare Workers with Postgres, and you can deploy it to your own Cloudflare account or run the exact same Worker as a single Docker container. Indexes federate over WebFinger, the same discovery mechanism the Fediverse uses, so a handle on your index resolves from anyone else's.
If Identizen the company disappeared tomorrow, your users would still be able to log in. The phone is the identity. The rest is standards.
The Trade-Off
I'm not going to pretend this is free. The 24 recovery words are the only recovery path. Lose your phone and your recovery words, and that identity is gone. There's no support line that can reset it, because the whole point is that nobody holds a master key.
I thought hard about social recovery and similar schemes and left them out, on purpose. Every recovery mechanism is also an attack path, and "call support and convince them you're you" is how most account takeovers actually happen. For a lot of people and a lot of sites, that trade is worth it. For some it won't be, and that's a legitimate call to make.
Identizen is live at identizen.com, and the platform is open source. If you're rethinking authentication for your product, or you'd like an architecture review of the auth you already have, book a call.