Compare
Identizen and passkeys solve different layers.
Passkeys are the best credential ever put in front of an account. Identizen asks why a person needs an account at the provider at all. This page compares them honestly, so you can pick, or use both.
Comparison
| Topic | Passkeys | Identizen |
|---|---|---|
| What it is | A phishing-resistant credential (WebAuthn / FIDO2) that a site stores against an account it already holds. The site is the identity provider; the passkey replaces the password. | An identity provider. The phone holds one identity, and sites integrate it as a standard OpenID Connect provider. There is no account at the provider for the passkey to protect. |
| Where the key lives | In the platform authenticator or a password manager. Synced passkeys are copied between devices through Apple, Google, Microsoft, or the manager’s cloud; device-bound passkeys stay on one authenticator. | On the phone only, in the platform keychain or keystore behind the biometric. Never synced through anyone’s cloud. A new phone is set up from the 24-word recovery phrase. |
| One identity or many | One passkey per site, created at that site. Each is independent; losing access means recovery at each site separately. | One identity that derives a different key for every site. Recovery is one phrase for everything, and revocation of a phone reaches every site at once. |
| Phishing | Resistant. The credential is bound to the site’s origin and the browser enforces it. | Resistant. The site’s registered host is inside the signed assertion and the per-site key is derived from it. A signature for a lookalike domain verifies for nothing. |
| Signing in from a computer | A passkey on the same device, or the cross-device flow: the site shows a QR code, the phone scans it, and the two talk over Bluetooth to prove proximity. | The site shows a QR code and a two-digit match code; the phone scans and approves. After the first time the browser is paired and later logins push straight to the phone. On Chromium, the phone can be found over Bluetooth without a code when the person clicks to do so. |
| What the site learns | Whatever the account holds. The passkey adds a credential id and a public key; the account still has the email, name, and whatever else the site collected. | A per-site identifier, a session id, and a per-site device id. No email, name, or phone number in the token. Sites cannot match a person across each other. The site asks for profile data itself, once, if it needs it. |
| Approving a specific action | Authentication only. WebAuthn signs a challenge, not a human-readable action. Transaction confirmation is not part of what platforms implement today, so the site shows the details in its own page and asks for a fresh assertion. | Built in. The site’s server composes the text, the phone shows it, and the hash of that text is inside the signature. An approval for one amount and payee is useless for any other. Works from any backend through the Verification API, with no browser present. |
| Integration | WebAuthn on the front end, a credential store and ceremony logic on the back end, or a vendor library that wraps both. Fits inside the login system you already run. | A standard OpenID Connect client with PKCE, or the React button and the CLI that scaffolds the callback. Replaces the login, or binds to an existing one for step-up. |
| Who runs the infrastructure | The site, plus the platform vendors that sync the credentials. | The public index at index.identizen.com, or your own: the index is open source and runs on Cloudflare or in Docker. The index stores no secrets either way. |
| Maturity | A W3C and FIDO standard shipped in every major browser and OS, used by large sites in production. | Protocol v1 with public test vectors, an open-source index, apps in store review. No independent security audit yet. Read the threat model before you rely on it for something that matters. |
Passkeys are described as the WebAuthn specification and the major platforms implement them. Identizen is described as the code ships; the security page lists what it does not yet claim.
Choosing
Which one, or both
- Should I use Identizen instead of passkeys?
- If your site already has accounts and a login system, passkeys are the smallest change and a good one. If you want to stop holding a credential database entirely, want one identity per person that works from any browser, or need signed approval of specific actions, Identizen is the different layer that does that. They are not exclusive: a site can offer both.
- Are passkeys and Identizen equally phishing-resistant?
- Yes, by different mechanisms. Passkeys bind the credential to the origin and the browser enforces it. Identizen puts the site host into the signed assertion and derives the signing key from it, so a lookalike site gets a signature that verifies nowhere.
- Can I use Identizen as a second factor on top of passkeys?
- Yes. Keep your login as it is, bind the person’s phone once through enrollment, and push approvals to it for sensitive actions. The phone then signs the exact text of what is being approved, which passkeys do not do.
Try a login before you decide.
The playground runs a real login against the hosted index with a virtual phone in your browser.