Is there a service that handles passkey login for me?

Yes, several. A service can take over the WebAuthn work: the challenges, the passkey storage, the browser calls and the checks. Some services only add passkeys to the login you already run. Others run all of sign-in, with passkeys as one method among several.

One detail decides more than any feature list. Every passkey belongs to one domain, its RP ID (relying party ID), and whoever runs the passkey ceremony on that domain holds the passkeys. That decides whether one passkey works on all your sites, and whether your passkeys can move with you if you switch services.

What kinds of passkey services are there?#

Passkey add-ons run passkeys next to the login you already have. Your accounts, passwords and sessions stay where they are. You put the vendor’s SDK on your pages and call its API from your server. Because the WebAuthn calls run on your pages, the passkeys usually belong to your own domain.

• Corbado Connect adds passkey enrollment and sign-in to an existing identity provider or in-house login.
• Hanko Passkey API adds passkeys to an existing auth system. Hanko says plainly that it is not a full authentication solution: people need an account and a first sign-in elsewhere.
• Bitwarden Passwordless.dev is a passkey API and toolkit built to sit next to common authentication systems. Its code is open source.

Full auth providers run all of sign-in. Passkeys sit next to passwords, email codes and social login, and you get a session or tokens back. You either redirect people to the provider’s hosted login page or embed its components in your own pages. For a broader comparison of these providers, see alternatives to Auth0.

Products in this space change. Passage by 1Password, a passkey-first login service, was retired on January 16, 2026, and its customers had to move. Check that a service is still sold, and how you would leave it, before you build on it.

Which services handle passkeys today?#

Here is where common services stand in October 2026. Plans and limits change, so confirm the details in each vendor’s docs.

What should you check before you pick one?#

Fallback methods#

Not every device has a passkey yet, and people sign in on borrowed computers. Check which other methods the service offers, such as passwords, email codes, magic links or social login, and whether you choose which ones appear. Cross-device sign-in closes part of the gap: the person scans a QR code with a phone that holds the passkey, and Bluetooth checks that the phone is nearby.

Account recovery#

Ask what happens when someone loses every device. Synced passkeys come back with the person’s Apple, Google or password manager account, but a passkey on a single device is gone with it. Recovery often runs through email, which makes the inbox the real key to the account. Prefer a service that lets people keep several passkeys and tells you how it verifies a recovery.

Multiple domains#

A passkey works on its RP ID and that domain’s subdomains, nowhere else. A hosted login page solves this: every one of your domains sends people to the same login domain, so one passkey covers them all. Components embedded on your own pages tie passkeys to each domain instead. Clerk warns that passkeys aren’t portable between primary and satellite domains, and Auth0 lets a person enroll a passkey on only one of several custom domains.

Choose the login domain before launch. WorkOS advises setting up the custom domain before turning passkeys on, and Amazon Cognito says people must register again after an RP ID change.

Data export#

Ask whether you can export credential ids and public keys, and which RP ID they were made for. A passkey made for your own domain can keep working with another service or your own server, if you take its records along. A passkey made for the provider’s domain can’t follow you, so people create new passkeys after a move.

Standard protocols#

A full provider that speaks OpenID Connect (OIDC), the identity layer on top of OAuth 2.0, works with any OIDC library and is easier to replace later. Passkey add-ons use their own APIs and SDKs, so more of your code depends on one vendor.

Where loginos fits#

loginos is a hosted OpenID Connect provider with passkeys built in. The passkeys live on loginos.io, so your app never calls WebAuthn: it redirects to loginos and handles one callback. Because the passkeys belong to loginos.io, the same passkey works on every domain of your platform, and on every other platform that uses loginos.

The ID token’s amr claim (authentication method references, with values from RFC 8176) tells you how the person signed in: ["hwk"] after a passkey and ["pwd"] after a password.

app.get("/api/auth/login/single/callback", async (req, res) => {
  const [state, verifier] = (req.cookies.lo_flow ?? "").split(".");
  if (!state || req.query.state !== state) return res.status(400).send("Sign-in expired, try again.");

  const r = await fetch("https://loginos.io/oauth/token", {
    method: "POST",
    body: new URLSearchParams({
      grant_type: "authorization_code",
      code: String(req.query.code ?? ""),
      redirect_uri: `https://${req.get("host")}/api/auth/login/single/callback`,
      code_verifier: verifier,
      client_id: process.env.LOGINOS_APP_KEY,
      client_secret: process.env.LOGINOS_APP_SECRET,
    }),
  });
  if (!r.ok) return res.status(401).send("Sign-in failed.");
  const { user, id_token } = await r.json();

  // The ID token came straight from loginos over TLS, so reading its payload is enough here.
  const { amr } = JSON.parse(Buffer.from(id_token.split(".")[1], "base64url").toString());
  req.session.user = { ...user, passkey: amr.includes("hwk") }; // your own session
  res.redirect("/");
});

Against the checklist above:

• Fallback: passwords, for people who prefer them. loginos has no email codes, magic links or social login.
• Recovery: loginos sends no email yet, so there are no reset links. Weigh that if email recovery matters to you.
• Domains: any number per platform, all sharing one pool of people. Sign-in happens on loginos.io, with your platform’s name and logo, not on your own domain.
• Export: the passkeys belong to people’s loginos accounts, not to your domain, so they stay with loginos if you leave. Your member list is available through the Management API.
• Protocol: standard OpenID Connect with PKCE, so any OIDC library works. Start with the quickstart and the claims reference.

If you need social login, SAML, email sign-in or a login page on your own domain, one of the services above fits better.

Frequently asked questions#

Can I add a passkey service to an app that already has users?#

Yes. Passkey add-ons are built for that: people sign in the way they do today, then add a passkey. With a full provider, you migrate the accounts or link them. loginos lets each person link their existing account to their loginos account once, with no migration: see link existing accounts.

Does a passkey service see my users’ private keys?#

No. The private key stays in the person’s device or password manager, and the service only stores public keys and checks signatures. A breach at the service can still leak account data, so review its security as you would for any vendor.

Do I need a custom domain for passkeys?#

Not to make them work, but the domain decides who holds them. A passkey made on a provider’s default domain doesn’t carry over to a custom domain you add later. If you want a login domain of your own, set it up before people create passkeys.

Can I run passkey login without any service?#

Yes. Open-source WebAuthn libraries exist for Node.js, Python, Go, Java and PHP, and the core flows take a day or two with one. The work is in the details: recovery, autofill, several passkeys per person and testing. See how to add passkeys to your website and what running WebAuthn yourself takes.