Passkey-based authentication
A passkey is a password replacement based on public-key cryptography.
Instead of proving knowledge of a shared password, the user’s device proves that it holds a private key created specifically for that website or application.
Passkeys are built on Fast Identity Online 2 (FIDO2) standards:
- Web Authentication (WebAuthn): the browser Application Programming Interface (API) used by websites.
- Client to Authenticator Protocol (CTAP): communication between a client device and an authenticator, such as a phone or security key.
Mental model: The server stores a public key. The user’s device protects the matching private key. Login succeeds when the device signs a fresh server challenge.
Main components
| Component | Responsibility |
|---|---|
| Relying Party (RP) | The website or application that authenticates the user |
| Browser or application | Connects the relying party to the authenticator |
| Authenticator | Creates and uses the passkey; often the operating system, password manager, phone, or hardware security key |
| User verification | A device Personal Identification Number (PIN), fingerprint, or face check that unlocks use of the passkey locally |
The user’s fingerprint or face is not sent to the website. The local device only confirms that user verification succeeded.
Creating a passkey
- The user signs in or creates an account.
- The server sends the browser a one-time random challenge and account details.
- The browser asks an authenticator to create a credential for that website.
- The authenticator verifies the user locally using a PIN or biometric.
- It creates a public/private key pair scoped to the website:
- the private key stays with the authenticator or passkey provider,
- the public key and credential identifier are returned to the server.
- The server stores the public key against the user’s account.
The website never receives the private key.
Signing in with a passkey
- The user starts signing in.
- The server sends a new random challenge.
- The browser asks the authenticator for a credential valid for that website.
- The user approves with a PIN, fingerprint, or face check.
- The authenticator signs the challenge and website context with the private key.
- The server verifies the signature using the stored public key.
- If verification succeeds, the server creates the normal authenticated session.
The challenge is fresh for each attempt, so an old signed response cannot simply be replayed.
Server: "Sign this fresh challenge for example.com"
↓
Device: verifies user and signs with the private key
↓
Server: verifies the signature with the public keyWhy passkeys resist phishing
A password or one-time code can be typed into a convincing fake website.
A passkey is scoped to the legitimate website’s relying-party identity. The browser and authenticator include and validate the website context, so a credential created for example.com cannot be used by example-login.attacker.com.
Other benefits:
- no reusable password is sent to the server,
- every site receives a different credential,
- credential stuffing does not work,
- a breached server database contains public keys rather than login secrets,
- a captured authentication response cannot be reused for a new challenge.
Passkeys do not protect a fully compromised device or application, and weak account-recovery flows can still undermine the overall system.
Synced vs device-bound passkeys
Synced passkeys
- Encrypted and synchronized by a passkey provider across the user’s devices.
- Improve usability and recovery when a device is replaced.
- Security also depends on the provider account and its recovery controls.
Device-bound passkeys
- Remain on one authenticator, such as a hardware security key.
- Useful when policy requires stronger device control or limits on credential copying.
- Require a backup authenticator or a carefully designed recovery process.
A user can also use a phone’s passkey to sign in on a nearby computer through a cross-device flow, commonly started with a Quick Response (QR) code.
Comparison with other authentication methods
| Method | What the user proves | Main strengths | Main risks or costs |
|---|---|---|---|
| Password | Knowledge of a shared secret | Universal and easy to deploy | Phishing, reuse, credential stuffing, password resets, server-side password database |
| Password + Short Message Service (SMS) code | Password plus access to a phone number | Familiar second factor | Phishable; Subscriber Identity Module (SIM) swapping; message delivery cost and reliability |
| Password + authenticator code | Password plus possession of a shared TOTP secret | Works offline; stronger than password alone | Codes can still be phished; setup and recovery burden |
| Magic link or email code | Access to an email account | No password to remember | Security depends on email; links/codes can be forwarded or phished; delivery delays |
| Passkey | Possession of a private key plus local user verification | Phishing-resistant; no shared server secret; fast sign-in | Device/provider recovery, ecosystem support, and migration need deliberate design |
| Hardware security key | Possession of a device-bound FIDO credential | Strong phishing resistance and device control | Physical distribution, loss, replacement, and support cost |
TOTP means Time-based One-Time Password.
Passkeys vs tokens
Passkeys and tokens solve different parts of authentication:
- A passkey proves the user’s identity during sign-in.
- A session cookie, access token, or JSON Web Token (JWT) represents the authenticated session afterward.
After verifying a passkey signature, the server commonly issues a secure session cookie or token so the user does not perform a passkey ceremony on every request.
Bearer tokens must still be protected. Anyone who steals a valid bearer token may be able to use it until it expires or is revoked.
Passkeys replace passwords and some multi-factor login flows; they do not eliminate session management or authorization.
Architecture and rollout notes
- Generate challenges on the server, make them unpredictable, and verify that they are fresh.
- Validate the expected relying-party identifier, origin, challenge, signature, and user-verification result.
- Allow users to register more than one passkey.
- Provide a way to view, name, and revoke registered passkeys.
- Treat account recovery as part of the authentication threat model.
- Introduce passkeys alongside existing login methods before considering password removal.
- Monitor adoption, sign-in success, fallback usage, recovery rates, and account-takeover signals.
- Step-up authentication may still be appropriate for high-risk actions.
Interview answer
A passkey replaces a shared password with a public/private key pair scoped to a website. During registration, the authenticator creates the keys; the server stores the public key, while the private key remains protected by the user’s device or passkey provider. During login, the server sends a fresh challenge, the user unlocks the passkey locally with a PIN or biometric, and the authenticator signs the challenge. The server verifies the signature and then issues a normal session cookie or token. Because the credential is bound to the legitimate site and no reusable secret is sent, passkeys resist phishing, credential stuffing, and password-database theft.
Knowledge check — Q&A
Q: Does the server store the passkey’s private key?
No. It stores the public key and credential metadata. The private key remains with the authenticator or passkey provider.
Q: Is the user’s fingerprint sent to the server?
No. Biometric verification happens locally. The server receives cryptographic proof, not biometric data.
Q: Why is a passkey phishing-resistant?
The credential is scoped to the legitimate relying party. A fake domain cannot ask the authenticator to use another site’s passkey.
Q: Why does the server send a challenge?
The fresh random challenge proves that the signed response was created for the current login attempt and prevents replay of an old response.
Q: Is a passkey the same as a session token?
No. A passkey authenticates the user. A session token or cookie represents the authenticated session afterward.
Q: Can a passkey be used on multiple devices?
Yes, if it is securely synced by a passkey provider. Device-bound passkeys remain on one authenticator.
Q: What happens if the user loses a device?
They may use a synced copy, another registered passkey, a hardware security key, or the service’s recovery flow. Recovery design is therefore critical.
Q: Are passkeys multi-factor authentication?
A user-verified passkey combines possession of the authenticator with local PIN or biometric verification. Whether it satisfies a specific regulatory definition depends on that regime’s requirements.
Q: What is the biggest migration risk?
A secure passkey flow can still be bypassed by a weak password fallback or account-recovery process.