Passkey
A login key stored on your phone or laptop, unlocked with a face, fingerprint, or PIN. Nothing to type, nothing to phish.
See it
What it is
A passkey is a private key stored on your device (phone, laptop, hardware key, password manager) that gets unlocked by a face, fingerprint, or device PIN. Your app stores only the matching public key. Login is a signed challenge, so there is no shared secret to leak, reuse, or type into the wrong site. The standard underneath is WebAuthn, and the browser API is navigator.credentials.
The property that matters most is phishing resistance: a passkey is bound to a relying party ID, a domain you choose at registration, and the browser will only use it on that domain or on subdomains of it. Set the RP ID to app.example.com and the credential stays there; set it to example.com and you have deliberately opened it to every eligible subdomain. Either way a lookalike site cannot get a valid signature, no matter how convincing the email was. That is a category difference from SMS codes or authenticator apps, which a user can be tricked into reading aloud. Most consumer passkeys now sync through iCloud Keychain, Google Password Manager, or 1Password, so one dead phone is not one dead account. Device-bound passkeys, the kind on a hardware key or a managed laptop, do not sync at all, which is why every user needs a second registered credential or a real recovery path.
Gotchas: the relying party ID is fixed at registration, so moving from app.example.com to example.com invalidates existing passkeys, and localhost credentials will not work in production. Support is uneven on older devices and locked-down corporate machines, so keep a fallback path and offer to register a second passkey. And do not build your account-recovery flow around emailing a link, because a phishable recovery route quietly undoes the phishing resistance you just bought.
Ask AI for it
Add passkey sign-in using WebAuthn through [library, for example SimpleWebAuthn]. Read the relying party ID from config and validate it against the production origin at startup rather than hardcoding an apex domain, and only widen it past the app's own host if cross-subdomain login is genuinely intended. On registration, call navigator.credentials.create with a server-generated challenge, residentKey 'required' so the credential is discoverable and passkey autofill actually works, and an explicit userVerification policy (state which one and why), then store the credential ID, public key, sign count, and transports. On login, show a conditional-UI autofill prompt on the email field and verify server side: challenge, origin, relying party ID hash, signature, credential ID, and the user-present and user-verified flags. Let users name and manage multiple passkeys in account settings, prompt to add a second one, and make the fallback another passkey, a hardware key, or a carefully verified recovery code rather than an emailed link.