This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 1, 2026. Spotted a mistake? Tell us.
A password is a shared secret: the user knows it, the server stores a hash of it, and anyone who learns it can use it. A passkey is a key pair: the private key stays on the user's device or in their platform keychain, and the server only ever sees the public key.
That one change fixes several problems at once — and creates one new one.
The mechanics
With a passkey (a WebAuthn credential):
- The server sends a random challenge.
- The authenticator signs it with the private key, after the user unlocks the device.
- The server verifies the signature with the stored public key.
Nothing reusable crosses the network. There is no secret to phish, no password to reuse across sites, and no hash database that becomes a credential dump when leaked.
Side by side
| Password | Passkey | |
|---|---|---|
| What the server stores | Password hash | Public key |
| What the user knows | A secret they can type anywhere | Nothing — the key stays on the device |
| Phishing | Works: a fake login page captures the password | Does not work: the signature is bound to the real origin |
| Reuse across sites | Common and dangerous | Not possible; each credential is per site |
| Breach impact | Password hash cracking; credential stuffing | No secret to steal from the server |
| Sync and recovery | "Forgot password" email | Platform keychain or a second device |
| Works on shared computers | Yes | Yes, with a device-bound security key or a phone |
What gets better
- Phishing resistance. The authenticator checks the origin; a lookalike domain gets no signature. This is the single biggest improvement, because phishing is how most account takeovers start.
- No credential stuffing. There is no password to reuse, so breaches at other companies cannot be replayed against yours.
- Less to store. A public key is not a secret. A database leak does not hand attackers usable credentials.
- Faster logins. One biometric check instead of typing and copy-pasting codes.
What does not change
- Account recovery is still the weak point. If a user loses every device, the recovery flow decides the real security level. A recovery email that resets everything undoes the passkey's protection.
- Session management still matters. A stolen session cookie is a stolen session, passkey or not. Keep session lifetimes and device lists under control.
- Not every user has a passkey-capable device. Older hardware, locked-down enterprise machines and shared kiosks need alternatives.
What gets harder
Support. "I lost my phone" becomes the most common ticket. Plan for it:
- Let users enroll more than one passkey, ideally on different devices.
- Provide a re-enrollment path after an identity check, with logging.
- Decide whether recovery can fall back to a password — and if it can, treat that password as the weakest link.
Synced vs device-bound. A synced passkey (iCloud Keychain, Google Password Manager) survives losing a device but depends on the platform account. A device-bound key never leaves the hardware but is gone if the key is lost. Both are useful; the recovery plan differs.
The migration path
- Offer passkeys alongside passwords. Do not remove the password on day one.
- Prompt enrollment after a successful login, not during a failed one.
- Track adoption per group and require passkeys for administrators first.
- Harden recovery before removing passwords. Recovery is the actual security boundary.
- Retire passwords for the groups that are ready, keeping a documented fallback.
How Casdoor handles passkeys
Casdoor supports WebAuthn credentials as a sign-in method, so users can register a passkey and sign in without a password. The same organization can keep passwords, MFA and social login during the transition, which is what makes a staged rollout practical. See the WebAuthn documentation.
Related reading: what passkeys are, passwordless authentication and MFA vs 2FA.
Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.
Sources
Product names are trademarks of their respective owners.