Accountless identity
What is accountless identity?
Accountless identity means there is no identity-provider account to create, protect, reset, or breach. The person’s phone holds a cryptographic identity, their biometric unlocks it, and every application receives a standard OpenID Connect assertion.
Traditional authentication begins with an account.
Someone stores an identity record. The person establishes credentials for it. Logging in proves possession of those credentials. Passwordless improves the credential. Multi-factor adds more of them. The account, and the database of accounts, stays.
Accountless identity removes the account. There is no record at a provider that a credential protects, so there is nothing to reset, phish, stuff, or breach. What exists is a key on the person's phone and a signature the phone produces when the person approves a request.
Accountless does not mean an application cannot keep user data. It means the identity does not depend on a credential account at a provider. Your app still stores whatever it needs under the per-site identifier it receives; nothing at Identizen can sign in as the user.
The properties
What has to be true for it to work
-
The phone holds the identity
A 256-bit seed is generated on the phone and stays there. Everything else is derived from it. The seed is shown once as 24 words so it can be restored on a new phone.
-
The biometric unlocks it
Face ID or a fingerprint authorizes one signature for one request. The biometric never leaves the device and is never the identity; the key is.
-
A different identity for every application
Each site gets its own derived key and its own stable identifier. Two sites cannot match a person by identifier, and the index never hands a site an email or phone number.
-
Applications consume standard OIDC
Your app is an OpenID Connect relying party with PKCE. Any OIDC library works. The id_token carries a per-site sub, session id, and how the person approved.
-
The index is a phonebook, not a vault
The index stores public keys, push tokens, per-site identifiers, an audit trail and, for paired browsers, a public key plus the browser’s user-agent and last IP. It routes requests and verifies signatures. It cannot approve a login by itself.
-
Open, self-hostable, federated
Apache-2.0. Run your own index on Cloudflare or in a container; handles resolve across indexes with WebFinger. Sites talk to one index; a phone registers with one index at a time (multi-index identities are planned).
What the identity can do
Authenticate. Verify. Authorize.
-
“I am this identity.”
Authenticate
Sign people into your app without a password or a provider account. Your app receives a standard OIDC id_token with a per-site identifier.
-
“It is really me, right now.”
Verify
Ask the phone for a fresh biometric approval when a session needs more assurance: a new country, a sensitive page, an admin console.
-
“I approve this specific action.”
Authorize
Send the exact action to the phone. The person reads it, approves it, and the signature is bound to that text, so it cannot be reused for anything else.
Fair comparisons
Where it sits next to what you know
- Is this the same as passwordless?
- Passwordless replaces the credential and keeps the account. Accountless removes the identity-provider account. Passkeys are a good passwordless credential; they still authenticate an account that a platform or a site owns.
- What about passkeys specifically?
- Passkeys are phishing-resistant credentials synced through Apple, Google, or a password manager and bound to one site each. Identizen keeps one identity on the phone, uses it from any browser through a QR code, push, or Bluetooth, gives every site its own identifier, and can approve a specific action with the details shown. It is a different layer, not a competing credential.
- What does the hosted index learn?
- Which identities are registered and which sites they sign in to, because it routes the requests. Sites cannot match a person across each other: the identifier and the device id in the token are both derived per site. If routing metadata should not leave your organization, run the index yourself.
- How does an app attach a name, email, or billing to an accountless identity?
- Through the sub claim, which is unique to the app, stable across phones and restores, and bound by the index to the key that produced it. A login with an unknown sub is a sign-up: the app asks for what it needs, once, and stores it under that sub. Identizen never receives it. See the demo bank at jtmerlin.com for the flow and its source.
- What if the phone is lost?
- Restore on a new phone from the 24 words, then revoke the old phone from the dashboard or another device. Revocation signs it out of every site and unpairs every browser it had paired.
More in the FAQ and the protocol specification.
See it work before you read more.
The playground runs a real login against the hosted index with a virtual phone in your browser.