1001Ferramentas
🔐 Security

WebAuthn Options Explainer

Explains each PublicKeyCredentialCreationOptions field (attachment, userVerification, residentKey) for developers.

The three options that decide whether your WebAuthn is a passkey or a second factor

When calling navigator.credentials.create, three fields define login behaviour, and the combination between them is what separates a real passkey from an ordinary second factor. Getting this wrong produces a system that appears to work but does not do what you pictured — usually still demanding a password forever, when the point was to remove it.

authenticatorAttachment picks the kind of authenticator: platform accepts only what is built into the device, such as Touch ID and Windows Hello; cross-platform accepts only external keys such as a YubiKey; omitting it accepts both. userVerification decides whether the authenticator must confirm who is present, via biometrics or a PIN, or whether detecting presence is enough. residentKey decides whether the credential is stored on the authenticator with its own identifier — which is what allows signing in without typing a username.

Pick the three options and the page explains each choice and delivers the verdict: with userVerification required and residentKey required, you have a passwordless setup; in any other combination it is classic 2FA and the password is still needed. Worth noting that a required residentKey consumes storage on the authenticator — older security keys hold only a few dozen credentials.

Frequently asked questions

Are passkeys and WebAuthn the same thing?
WebAuthn is the browser API. Passkey is the name that stuck for a discoverable credential — the one stored on the authenticator, usually syncing across devices through an Apple, Google or password-manager account. Every passkey uses WebAuthn, but not every use of WebAuthn is a passkey.
Should I set userVerification to required?
For passwordless, yes: without verifying who is present, whoever holds the device gets in. For a second factor after a password, preferred is reasonable, since the password already identified the person. What rarely makes sense is discouraged in a passwordless flow.
Does the server need to store the public key?
It does, alongside the credential identifier and the signature counter. The private key never leaves the authenticator — that is the difference from a password, which exists on both sides. It is why a database leak does not compromise accounts using passkeys.

Related Tools