Add Passkeys With a Managed Passkey API

A passkey API runs the WebAuthn server for you: the challenges, the verification, the credential storage and the fallback. The Bridge is one platform for auth, billing and feature flags, so passkeys arrive as a per-app setting on the same user who already carries your roles and plans.

Passkeys in the docs

Enterprise-grade & compliant by default

<script>
  // Drop-in login for SvelteKit
  import { LoginForm } from '@nebulr-group/bridge-svelte';
</script>

<LoginForm />

<!-- Turn passkeys on in the Control Center.
     No redeploy: LoginForm reads the app config. -->

Roll it out on your terms

A setting, not a migration

A 2-minute setup adds The Bridge to your app and gives you a login component. After that, passkeys are one switch: the button appears on your sign-in screen with no redeploy.

Flip it, watch your login screen update live.

The fastest way to add it

Turn passkeys on by asking

The Bridge is built for AI editors. Point your agent at the command line and it wires passkey login for you.

✦ CLI-drivenClaude CodeCursorAny AI editor

Your agent runs the setup, you review the diff

Passkey setup is one documented command plus a drop-in component, which is exactly the shape an agent gets right. It enables passkeys, adds the login component and the setup page, and keeps a fallback method on, with no WebAuthn code for you to review.

Read the passkeys guide

Prefer to wire it yourself? The same steps are in the docs, one component at a time.

What you skip

What the passkey API handles for you

Each card is work you would otherwise build, test and keep up to date yourself.

Every passkey checked

We create the challenge and check the response whenever a user adds a passkey or signs in with one, on our servers.
WebAuthn
Storing the keys

The public key and credential details are stored against the user. The private key stays with the user.
Storage
Passkeys on your domain

With in-app login, a passkey made on app.acme.com also works on www.acme.com and your other subdomains.
Your domain
Only your sites

Only the web addresses listed in your app's settings can create or use a passkey. Anything else is refused.
Allowed origins
Adding a passkey

Users ask for a setup link and add a passkey from their inbox, on whichever device they are holding.
Setup links
Another way in

Password sign-in is always there, and magic link and Google sign-in switch on per app, next to passkeys.
Fallbacks
A lost device

The user signs in another way and adds a new passkey from an emailed setup link.
Recovery
Your login, your layout

Use our hosted login page, or build login into your own app from the SDK components. Pick before users enrol: passkeys made on our page belong to our domain.
Hosted or in-app

And of course

First-class SDKs for every stack

Type-safe, batteries-included SDKs with drop-in components, and the same clean user object everywhere.

Next.js

Svelte

Astro

Node

FastAPI

Laravel

Flutter

React

Angular

Nuxt

Deno

Python

Rust

Ruby

Kotlin

Vue

SolidJS

Remix

Bun

Django

PHP

.NET

NestJS

…and 24+ frameworks & languages supported. Hover to pause, drag or swipe to explore.

Build it yourself vs. using The Bridge

What a hand-built passkey integration asks of your team, next to what The Bridge asks of you.

Building it yourself

Four endpoints to add passkeys and sign in with them
A credential table, one user to many passkeys
Setup emails, a fallback, and a plan for users who lose every device
Keeping up with browser and spec changes

With The Bridge

Add the login component and a setup page once, in 2 minutes, then passkeys are one setting
Credentials stored against the user for you
Setup links built in, fallback methods switched on per app
Hosted login page or your own components, your choice

What the credential lands on

Passkeys on the user you already have

A verified passkey is only half the job. It also has to land on a user your product already knows.

Passkeys as a service, on the same user as your roles and plans

A passkey-only service gives you a verified credential and leaves you to join it to your own users, roles and billing. With The Bridge the passkey lands on the user object that already carries roles, plan and feature flags, so there is no second user store to keep in step.

The hard part of adding a standalone passkey service is rarely checking the passkey. It is the join: mapping the provider's credential to your user, keeping both sides in step when someone is deleted or changes email, and deciding which system owns the truth about who a person is.

With The Bridge that join never exists, because the platform that verifies the passkey is the one that holds the user. A passkey is one more login method on an account that already has roles and a plan, and every method, passkey or magic link or Google, returns the same user object. For a careful rollout, show the passkey prompt only to users behind one of your own feature flags.

Keep a second sign-in method on next to passkeys. Someone will always arrive on a device with no passkey on it, and a fallback such as magic link login gets them in. For how passkeys work under the hood, read how to implement passkeys, and for how the rest of the identity layer fits together, start with the SaaS authentication guide.

Common questions

Do you store our users' passkeys?

We store the public half. A passkey is a key pair, and the private key never reaches The Bridge or you: it stays with the user, on their device or synced end-to-end encrypted by their credential manager, unlocked by a biometric or PIN. The Bridge holds the credential ID, the public key, the signature counter and the transports against the user, which is everything verification needs. There is no shared secret on our side or yours to leak.

Which devices and browsers are supported?

Passkeys are a web standard, so support comes from the browser and the device: Face ID and Touch ID on Apple devices, Windows Hello, Android screen lock, password managers that store passkeys, and hardware security keys. Passkeys sync inside a provider such as iCloud Keychain or Google Password Manager, not freely between providers, which is one more reason to keep a fallback method on.

What happens if a user loses every device?

They sign in through the fallback method you keep enabled, such as a magic link or a password, and then enrol a new passkey from an emailed setup link. A passkey cannot be emailed to anyone, so recovery always runs through another method you trust. The passkeys guide in the docs covers setup links and fallbacks.

Can we self-host the passkey API?

No. The Bridge is a managed cloud service, and that is what the Control Center setting switches on. You never run a WebAuthn server, a challenge store or a credential database yourself, and the private keys stay with your users, never with us or you.

How do signed-in users add a passkey?

Through a setup link. The user asks for one, The Bridge emails it to the address on their account, and they enrol the passkey from that link, on whichever device they are holding. Tying enrolment to the inbox means a stolen session alone cannot add an attacker's passkey to someone's account. The same setup link is how a user who lost a device enrols a replacement.

What happens to our passkeys if we move off The Bridge?

It depends on the login mode, because a passkey is bound to one domain for life. Passkeys created on the hosted login page are bound to thebridge.dev, so they cannot follow you to another provider, and users would enrol again. Passkeys created with in-app login are bound to your own domain, not ours, which is the precondition for keeping them with another provider. If portability matters to you, choose in-app login.

How do we move existing password users to passkeys?

Gradually, and without forcing anyone. Keep your current login method on, switch passkeys on next to it, and let users enrol when it suits them through a setup link. Passwords keep working the whole time, so nobody is locked out, and you can watch adoption before deciding whether passwords should ever go.

Does it work with our existing login?

Yes, that is the normal case. Each login method is a per-app setting, so passkeys switch on next to email and password, magic links or social sign-in, and the sign-in screen picks up the change with no redeploy. That screen can be the hosted login page or the same flows built from SDK components inside your own layout.