The Persistent Password Problem
Developers and users have long accepted passwords as a necessary evil. They create friction during onboarding, drive cart abandonment in ecommerce flows, and remain the weakest link in most authentication systems. Password reuse, weak choices, phishing sites, and credential-stuffing attacks continue to dominate breach reports from major organizations.
Passkeys, built on the WebAuthn and FIDO2 standards, offer a standards-based alternative that eliminates shared secrets. Instead of transmitting passwords, the browser and operating system handle private key operations locally while only public keys are stored on servers. This approach delivers both improved security and a smoother user experience.
Core Architecture: WebAuthn, CTAP and FIDO2
WebAuthn is a W3C web API that allows websites to interact with authenticators. These authenticators can be platform-based (Touch ID, Windows Hello, Android biometric) or roaming (security keys). The Client to Authenticator Protocol (CTAP) handles communication between the client device and the authenticator. Together they form the FIDO2 project.
The cryptographic foundation relies on public-key cryptography. During registration, a private-public key pair is generated. The private key never leaves the authenticator. Only the public key, along with metadata, is sent to the relying party (your server). Authentication then becomes a challenge-response protocol using that key pair.
Registration Flow in Detail
The registration process involves several steps between the browser, authenticator, and your backend. The server first generates a random challenge and sends it to the frontend. The frontend calls the WebAuthn API, which prompts the user to authenticate using biometrics or PIN. The authenticator creates a new key pair bound to your origin and returns an attestation object.
Your backend must then verify the attestation, extract the public key, and store it associated with the user account. Storing only the public key means that even if your database is compromised, attackers cannot impersonate users without physical access to their devices.
Frontend Registration Code Example
async function registerPasskey(userId, email) {
// Challenge and user data come from your backend
const response = await fetch('/auth/register-options', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ userId, email })
});
const options = await response.json();
// Convert base64 strings to ArrayBuffers as required by the API
options.challenge = base64ToArrayBuffer(options.challenge);
options.user.id = base64ToArrayBuffer(options.user.id);
const credential = await navigator.credentials.create({
publicKey: options
});
// Send attestation back to server
const result = await fetch('/auth/register', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
id: credential.id,
rawId: arrayBufferToBase64(credential.rawId),
response: {
attestationObject: arrayBufferToBase64(credential.response.attestationObject),
clientDataJSON: arrayBufferToBase64(credential.response.clientDataJSON)
},
type: credential.type
})
});
return result.ok;
}Authentication Flow
Authentication follows a similar challenge-response pattern. The server issues a fresh challenge tied to the specific user or session. The browser calls navigator.credentials.get() with the appropriate options, the authenticator signs the challenge using the previously registered private key, and the signature is sent back for verification.
Because the private key is bound to the origin and the challenge is unique and random, replay attacks and phishing become significantly harder. The authenticator will only sign for the exact relying party ID that was registered.
Frontend Authentication Code Example
async function authenticateWithPasskey() {
const response = await fetch('/auth/login-options', {
method: 'POST',
headers: { 'Content-Type': 'application/json' }
});
const options = await response.json();
options.challenge = base64ToArrayBuffer(options.challenge);
if (options.allowCredentials) {
options.allowCredentials.forEach(cred => {
cred.id = base64ToArrayBuffer(cred.id);
});
}
const assertion = await navigator.credentials.get({
publicKey: options
});
const result = await fetch('/auth/login', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
id: assertion.id,
rawId: arrayBufferToBase64(assertion.rawId),
response: {
authenticatorData: arrayBufferToBase64(assertion.response.authenticatorData),
clientDataJSON: arrayBufferToBase64(assertion.response.clientDataJSON),
signature: arrayBufferToBase64(assertion.response.signature),
userHandle: arrayBufferToBase64(assertion.response.userHandle)
},
type: assertion.type
})
});
return result.ok;
}Backend Responsibilities
The server performs critical verification steps that cannot be trusted to the client. For registration, you must:
- Validate the challenge matches one you issued
- Verify the origin and relying party ID
- Check attestation if using high-security requirements
- Extract and store the public key (COSE format) and credential ID
- Store transport hints and user verification details
For authentication, the server verifies the signature against the stored public key, validates the authenticator data flags, and ensures the challenge matches. Libraries like @simplewebauthn/server handle most of these cryptographic details correctly, but understanding the underlying data structures remains important for debugging and custom implementations.
Choosing Authenticator Attachment and User Verification
The authenticatorSelection object gives developers control over the user experience. Setting authenticatorAttachment to "platform" prefers built-in device biometrics. Setting it to "cross-platform" encourages security keys. The userVerification field can be "required", "preferred", or "discouraged".
For consumer applications, preferred with platform authenticators usually provides the best balance between security and friction. Enterprise applications with strict compliance needs may require "required" and hardware security keys.
Handling Device Sync and Recovery
One of the strongest advantages of modern passkey implementations is cloud sync. Apple, Google, and Microsoft all sync passkeys across a user's devices when signed into their respective ecosystems. This removes the "I bought a new phone and now I can't log in" problem that plagued earlier FIDO deployments.
However, this introduces recovery considerations. If a user loses access to all synced devices, you still need backup authentication methods. Many production systems implement a recovery code or secondary email-based flow that can be used once to register a new passkey. The design of these recovery mechanisms requires careful threat modeling.
Progressive Enhancement and Fallback Strategies
Adopting passkeys does not require a complete cutover. A practical pattern is to offer passkeys as an enhancement for users who have capable devices while continuing to support traditional authentication. After a successful passkey login, you can prompt users to enroll additional passkeys or convert their password account.
Feature detection is straightforward:
function supportsPasskeys() {
return window.PublicKeyCredential &&
typeof window.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable === 'function';
}Always test the actual availability of a platform authenticator using the isUserVerifyingPlatformAuthenticatorAvailable() method before presenting the option to users.
Security Advantages Quantified by Design
Passkeys eliminate several classes of attacks:
- Phishing: The private key is bound to the exact domain. The browser will not use it for a fake site even if the user is tricked into visiting it.
- Credential stuffing: There are no reusable passwords to stuff.
- Database breaches: Stolen public keys cannot be used to authenticate without the corresponding private key on a registered device.
- Man-in-the-middle: The challenge-response protocol and signature validation prevent interception attacks.
The WebAuthn specification also includes mechanisms for attestation that allow high-assurance environments to verify the make and model of the authenticator hardware or software.
Common Implementation Pitfalls
Several mistakes appear frequently in production deployments. Using the same challenge for multiple operations, failing to validate the full clientDataJSON (especially the origin and challenge fields), and not properly encoding binary data as base64url are recurring issues.
Another frequent error is storing too little metadata about the credential. Recording the transports array helps with future authentication performance. Logging the authenticator GUIDs (AAGUIDs) can also help with support and analytics without compromising privacy.
Testing across browsers requires real hardware. Emulators often behave differently from physical authenticators, especially regarding user verification and attestation.
Production Considerations for Startups
For resource-constrained teams, start with the excellent open-source libraries available in multiple languages. The simplewebauthn suite provides battle-tested implementations for both frontend and backend. Focus first on the happy path with platform authenticators, then expand to security key support based on user feedback.
Consider the user journey carefully. Clear explanations about what passkeys are and how they improve security help with adoption. Some teams have seen success by framing passkeys as "passwords that can't be stolen or forgotten."
Monitoring is important. Track passkey registration success rates, authentication failure reasons (when available), and fallback usage. These metrics help you refine the experience over time.
Evolving Standards and Browser Support
WebAuthn Level 2 is widely supported across modern browsers. Level 3 is in active development with improvements to conditional mediation, passkey autofill, and enterprise features. Conditional UI (the ability for passkeys to appear in standard username fields) is already shipping in Chrome and Safari, dramatically improving the user experience.
The authentication community continues to refine best practices around discoverable credentials (resident keys) versus non-discoverable ones. For most consumer applications, discoverable credentials provide the smoothest experience because the username does not need to be entered first.
Conclusion
Passkeys represent one of the most significant improvements in web authentication in decades. They combine strong cryptographic security with consumer-friendly biometrics while removing the cognitive burden of password management. The WebAuthn API, while initially intimidating due to its binary data handling and ceremony requirements, becomes manageable with good libraries and clear patterns.
Teams that implement passkeys thoughtfully see higher conversion rates, lower support costs, and meaningfully improved security posture. The technology has moved beyond early-adopter status and is now ready for mainstream production use across web applications of all sizes. Starting with a progressive implementation that augments existing authentication flows provides the lowest risk path to capturing these benefits.
The combination of better security and better user experience is rare in our field. Passkeys deliver both. The patterns and code shared here should give any full-stack team a solid foundation for successful deployment.