Implementing Passkeys in a SaaS Product: A Practical Guide

When a user registers, their device generates a key pair. The private key stays on the device or in their credential manager, and your server stores the public key. At sign-in, your server sends a random challenge, the device signs it after the user verifies with biometrics or a PIN, and your server checks the signature against the stored public key. No shared secret exists to phish or leak from your database.

Two properties matter for design. Passkeys are bound to your relying party ID, normally your domain, so a look-alike site can't request them. And many passkeys sync across a user's devices through their platform's credential manager, while others are bound to a single hardware key. Your app doesn't control which, so plan for both.

Design these on both server and client:

1. Registration: after the user proves who they are another way, request a challenge, call the browser's credential creation API, and store the returned public key, credential ID and metadata.
2. Sign-in: request a challenge, call the browser's credential retrieval API, verify the signed response, and start a session.
3. Autofill sign-in: use the browser's conditional UI so passkeys appear in the username field's suggestions, which removes a step for returning users.
4. Management: let users list, name and remove passkeys, and register more than one.
5. Recovery: define what happens when someone loses every device.

Validate on the server that the challenge matches, the origin and relying party ID are correct, and the signature counter and flags make sense. Use a well-maintained WebAuthn library instead of writing the checks yourself.

Recovery is the weakest link. If recovering an account only needs an email link, an attacker with the mailbox bypasses the passkey. Options, from lower to higher assurance:

• Encourage users to register at least two passkeys, for example one on a phone and one in a password manager.
• Offer backup codes generated at enrollment and stored by the user.
• Allow email-based recovery, but add a delay, notification to existing devices and stricter checks for sensitive changes.
• For business accounts, let an organization admin verify and reset a member, with an audit trail.
• For high-risk accounts, require support-assisted verification with documented steps.

Pick a level that matches your customers' risk. Consumer products lean toward convenience; products holding financial or health data lean toward stricter recovery.

Add passkeys alongside existing methods first. Prompt users to create one right after a successful password or magic-link login, when they're already authenticated and motivated. Track how many users enroll, the sign-in success rate and time to sign in, and support tickets, and compare passkey and password cohorts.

Roll out in stages: internal accounts, a small share of customers, then everyone. Later you can make passkeys the default and hide passwords, but keep an escape hatch. For B2B products, remember customers with SSO may prefer their identity provider; the relationship is covered in adding SAML SSO to a B2B SaaS app.

A library handles the cryptography, but you still own the database schema, flows, recovery, browser quirks and ongoing updates as platforms change. Providers offer passkeys as a feature: Clerk provides drop-in sign-in components and user management, while Stytch offers headless APIs when you want to build your own interface. Ask in a demo how each handles enrollment prompts, multiple passkeys per user, recovery and organization policies, and what they charge.

If you already use a hosted identity provider, check whether passkeys are included before building. For provider comparisons see Auth0 vs Clerk vs Stytch, Clerk vs Auth0 for B2B SaaS and Auth0 vs Clerk for software publishers.