How to Add Passkeys to Your App

A passkey is a key pair. The private key stays on the user's device, protected by Face ID, Touch ID, or a PIN, and the public key lives with you. Nothing shared and reusable ever crosses the wire, which is why passkeys resist phishing and credential stuffing in a way passwords never could.

There are three parts to plan for: the relying party (your app, identified by a relying party ID, the domain the passkey is bound to), the authenticator (the platform one built into a phone or laptop, or a roaming security key), and the two ceremonies that register and then use the credential. For the polished autofill experience you also need discoverable credentials and conditional UI, so the passkey is offered right in the sign-in field.

If you are still mapping how this fits with sessions, social login, and roles, start with the SaaS authentication guide. With The Bridge, passkeys are a toggle on the hosted login box, with ceremonies, key storage, device quirks, and fallbacks handled on the same user model that carries plan and feature flags. They run on The Bridge's own login in production today.

Registration starts when your server sends creation options with a fresh challenge. The browser calls navigator.credentials.create(), the authenticator generates the key pair, and you store the returned public key, its credential ID, and a signature counter against the user.

Sign-in mirrors it. Your server sends a random challenge, the browser calls navigator.credentials.get(), the authenticator signs the challenge with the private key, and your server verifies that signature against the stored public key. Get the relying party ID wrong, reuse a challenge, or ignore the signature counter, and authentication either fails or quietly weakens.

Two experience details matter. Conditional UI lets the browser surface a passkey in the email field before the user clicks anything. The cross-device, or hybrid, flow lets a phone approve a sign-in on a nearby desktop, using Bluetooth only for proximity and then an encrypted tunnel, so a user without a platform passkey on the current machine still gets in.

The Bridge runs both ceremonies as the relying-party server, so you never call the WebAuthn APIs or store a public key yourself.

The two API calls are the easy part. A production build is the work around them:

• HTTPS everywhere, and a relying party ID that is a registrable suffix of your origin (the apex example.com covers www and other subdomains, but not the reverse, which breaks more demos than anything else).
• A server library to verify responses correctly. Most teams reach for SimpleWebAuthn rather than parsing attestation and assertion data by hand.
• A credential storage schema: public key, credential ID, signature counter, transports, and the user it belongs to.
• Challenge endpoints that issue and validate a fresh challenge per ceremony, with no reuse.
• Real-device testing across iCloud Keychain, Android, and password managers like 1Password, because behavior genuinely differs.
• Recovery flows for the lost-device case, which is a separate problem from day-to-day login.

The classic failures are the quiet ones: a mismatched relying party ID, a reused challenge, or an ignored signature counter. None throw an obvious error, they just make sign-in flaky or less safe.

This list is exactly what The Bridge takes off your plate. You enable passkeys on the login box, and the relying-party server, storage, and device handling come with it.

Treat passkeys as an addition, not a migration. The teams that succeed roll them out as a second method behind an existing login, watch adoption, and never force every user to switch at once.

Always keep a fallback. Some users land on a device without a passkey, so offer add Google login as a fallback method or a magic link so nobody is locked out. Account recovery is a separate flow from that fallback: decide up front how a user who loses every device proves who they are, because a passkey cannot be emailed to them.

Plan for the ecosystem reality too. Passkeys sync within Apple, Google, and Microsoft accounts, but not freely across them, so a user deep in one ecosystem may not carry a passkey into another. That is a reason to keep fallbacks, not a reason to wait.

When should you not bother yet? If you have no existing login to sit behind, or your audience is on older devices, ship a solid password or social baseline first. With The Bridge you can flag-gate the passkey rollout to a beta cohort and turn it on for everyone when the numbers look right, all from the Control Center.