Phishing-resistant sign-in with WebAuthn and passkeys

What it is

The Web Authentication API lets a web application create and use public-key credentials. At registration, navigator.credentials.create() asks an authenticator (the platform's own, unlocked by biometrics or PIN, or a roaming security key) to generate a key pair; the server, called the relying party, stores the public key with the account. At sign-in, navigator.credentials.get() passes a server-generated challenge; after user consent the authenticator signs it with the private key and the server verifies the signature with the stored public key. The specification scopes each credential to a relying party identifier (RP ID), a domain string that defaults to the origin's effective domain and may only be overridden with a registrable domain suffix of it; a credential can only be used with the same entity, as identified by RP ID, it was registered with, and the client data covered by the signature includes the origin. Passkeys are WebAuthn credentials that are discoverable (the authenticator stores the private key and user handle, so no username needs to be typed first) and, in many implementations, synced between a user's devices by the platform vendor. MDN notes that on the web, passkeys are implemented with this API.

Why it matters

Passwords and one-time codes can be typed into a phishing page and relayed. MDN's summary of the defence: an attacker who creates a fake login site cannot log in as the user because the signature changes with the origin of the website. The server holds no secret that can be replayed, so a leaked credential table exposes only public keys.

How to apply

• Use a maintained server-side library for the registration and assertion ceremonies; verify the challenge, origin, RP ID hash and signature, and check the signature counter where the authenticator provides one.
• Choose the RP ID deliberately (the registrable domain if several subdomains share accounts) and keep it stable; changing it invalidates every credential.
• Allow several credentials per account, and design account recovery so that it is not weaker than the passkey it replaces.
• For passwordless sign-in request discoverable credentials and user verification; if the account model is not ready, offer passkeys as a second factor first.
• Store the credential id, public key, sign count and transports; the private key never reaches the server.

Pitfalls

Recovery flows (email reset links, support desks) become the phishing target once the primary factor is phishing-resistant. Attestation is optional, and MDN advises relying parties not to maintain allowlists of authenticators. Synced passkeys move trust to the user's platform account; device-bound credentials on security keys do not sync and need a second registered credential. Browser and platform dialogs differ; test on the devices your users have.