Passkeys beside passwords, without confusing anyone

Every application that signs in through EAuth offers passkeys, next to the password, on the same page. Nobody has to switch, nobody has to be told what a passkey is before they can use one, and the password does not go away. This post is about how the two live together, because that is where most passkey rollouts go wrong.

What a passkey is, in one paragraph

A passkey is a key pair. The private half stays on the person's phone, laptop or security key, protected by the device's own lock: fingerprint, face or PIN. The public half is registered with the site. Signing in means the site sends a challenge and the device signs it, after the person unlocks it. The site never sees a secret, so there is nothing to leak from our database, and the browser binds the passkey to eauth.me, so a copied sign-in page on another domain gets nothing the real one accepts. That last property is the one a password cannot have: a person who types their password into a convincing copy of the page has given it away; a passkey refuses to work there.

One page, two ways in

The EAuth sign-in page shows the email and password fields and, below them, "Sign in with a passkey". That is the whole interface. The button appears only after the page's script has checked that the browser can use a passkey, so a browser that cannot never shows a button that does nothing.

Behind it, the page asks the browser for conditional mediation. The email field is marked username webauthn, and a browser that holds a passkey for eauth.me offers it among that field's suggestions, the way it offers a saved password. A browser that holds none shows nothing extra. Nobody types an address first: the passkey the person picks names the account. The person who has a passkey uses it in one tap; the person who does not sees a normal sign-in page.

There is no separate "passwordless" mode to opt into and no prompt on every visit asking whether you would like to set one up. A prompt like that trains people to dismiss dialogs, which is the opposite of what security needs.

Where a passkey is made

On the account page, under Security, next to the second factor. Adding one asks for the password first. A passkey is a way in that survives a password change, so a browser somebody left signed in must not be enough to leave one behind, and wrong passwords there are counted: five per account in fifteen minutes. Then the device creates the key. The person can give it a name, "MacBook" or "iPhone", so the list means something a year later; without one, it is named after the browser and platform. Every addition is mailed to the account's address, with what to do if it was not them.

Removing one is a button and a confirmation. There is no lower bound: a person may remove their last passkey, because they still have their password.

Passkeys made on a phone or a laptop are usually synced by the platform, Apple's or Google's, to the person's other devices. EAuth records whether a passkey is synced and marks it on the account page, because it changes what losing a device means: a synced passkey survives it, a passkey on a hardware key does not. The export of a person's data that an application makes for a GDPR request carries the same mark.

A hardware key also keeps a counter that rises with every use. When it fails to rise, the key may have been copied, and EAuth does not merely refuse that sign-in: it removes the passkey, since a copy would keep working, and tells the person to sign in with their password and add a new one. Synced passkeys keep no counter and are not treated as copies.

Why the password stays

Two reasons, and neither is nostalgia.

A person's devices change. A new phone without the platform account signed in yet, a borrowed laptop, a company machine with a locked-down browser: each of these is a moment where the passkey is not at hand. The password is the way in, and the second factor still applies to it.

Recovery has to exist. With the password kept, losing a passkey loses nothing: the account still has its password, and a forgotten password is reset by a link to the confirmed address, as before. If the password went away, recovery would have to rest on that link alone, which is weaker than either. Keeping it means the passkey is a step up, not a step sideways.

What it does not do

A passkey is not a second factor for the password. A passkey whose device checked the person, with a PIN, a fingerprint or a face, is complete on its own: something they have and something they know or are. A passkey that only registered a touch, as some security keys do, counts as one factor, and an account that turned on a second factor is asked for its code, as after a password. Signing in with the password still asks for the code if the person set one up. The two are separate paths.

A passkey does not replace the limits on the password form either. An attacker who ignores the passkey and guesses passwords meets the same limits as before: twenty wrong passwords per account in fifteen minutes from anywhere, five from one address, counted before the password is checked. The passkey requests share the per-address limit of thirty sign-in requests a minute, so a passkey next to the form does not widen anything.

For developers

Nothing changes in your integration: no setting, no SDK call. A user who signs in with a passkey gets the same authorization code and the same ID token as one who used a password. The token does not say which of the two was used, so today you cannot treat passkey sign-ins differently. That is a limitation, and I would rather name it than have you look for a claim that is not there.

An account at EAuth belongs to one application. A person who uses two applications has two accounts and adds a passkey to each. Because every passkey belongs to eauth.me, the browser may offer both on either sign-in page; the one for the other application is refused with a message that says so, and nothing is signed in. Our own developer console and dashboard sign in through the same page, so developers get passkeys there as well.