Passkeys

Passkeys provide fast, phishing-resistant authentication with device-bound credentials.

Enable passkeys

Turn on passkeys in the Admin UI for your tenant and configure allowed origins.

How users create a passkey

Users create a passkey while they sign in with an emailed code. When your tenant has passkeys on and the user has none yet, the code page shows one quiet line under the code field: Sign in faster next time: create a passkey. Users who ignore it sign in as before. There is no extra step after sign-in.

Creation flow:

1. The user clicks the line. The browser asks them to create a passkey (fingerprint, face, screen lock or security key).
2. Authalla checks the new passkey and holds it, unsaved, for this sign-in. The line changes to Your passkey will be saved when you sign in.
3. The user enters the code, or opens the link from the email in the same browser. Once that signs them in, Authalla saves the passkey to their account and continues to your app.

A wrong code saves nothing, so typing someone else's email address is not enough to add a passkey to their account. If the user cancels the browser's prompt, or the passkey can't be verified, the line comes back and the sign-in carries on as before.

If the user opens the email's link on another device, the passkey isn't saved there. Their password manager may still offer it; the first time they use it, the sign-in page explains it no longer works and asks the browser to forget it.

How passkey login works

Passkeys use discoverable WebAuthn credentials so users can sign in without entering a username.

Login flow:

1. Passkeys login returns a login challenge.
2. The browser calls navigator.credentials.get().
3. Passkeys login validates the assertion, creates a session, and continues the OAuth2 flow.

Passkeys in the email field's autofill

When passkeys are on, the hosted sign-in page offers saved passkeys in the email field's autofill list, next to saved addresses. Picking one signs the user in without typing an email. This uses WebAuthn conditional mediation (autocomplete="username webauthn"), so it only appears in browsers that support it. It doesn't ask the server anything about the typed email, so it reveals nothing about which addresses have accounts.

The "Continue with passkey" button stays, last in the list of sign-in options, as the fallback: for browsers without conditional mediation, and for a passkey kept on another device, such as a phone reached by QR code.

When a passkey stops working

If a user signs in with a passkey that your tenant no longer has (for example, you removed it from the user in the dashboard), the sign-in page says: This passkey no longer works here. Sign in with your email, then create a new one. In browsers that support it, Authalla also tells the browser's passkey manager to forget that passkey, so it stops offering it.

Operational notes

• A passkey belongs to the sign-in address it was created on: the tenant's {tenant-id}.authalla.com address or its custom domain. Browsers don't offer it on the other address, so add a production custom domain before users create passkeys. See Environments.
• Users can register multiple passkeys; credentials are stored per user.

UX recommendations

• Offer passkeys as the default sign-in option.
• Provide a magic link fallback for unsupported devices.