PASSKEYS have been in the news recently and with good reason–the big tech companies are seriously ramping up efforts to move all their users to this newfangled tech.
But there's a fly in the ointment: certain influential tech people really dislike them. According to DHH:
if you sign up for a service on Windows, and you then want to access it on iPhone, you're going to be stuck (unless you're so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!)...A decent alternative to passkeys, if you need the extra layer of security, is to lean on email for the first login from a new device. Treating email as a second factor, but only on the first login from that device. Everyone has email, everyone understands email. (Just don't force us all to go through magic links exclusively, as that's a pain too for those who've actually adopted a password manager!).
DHH is very close to the ideal UX for passkeys for ordinary non-technical folks, but can't quite put it together. Here's what I recommend:
Initial user sign-up
- Don't make the user set up a password!
- Send a magic link to their email
- Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.
Subsequent logins on the same device
- Use Conditional UI to allow selecting the passkey directly from the Email input autocomplete. Browsers support this now!
- If JavaScript disabled: instead of Conditional UI and passkey login, send a magic link
Subsequent logins on a new device
- Send a magic link to the user's email address
- Once they click and enter the webapp, they are in a logged-in state. Prominently show a passkey setup CTA and ask the user to set up a passkey on the device.
Notice how this is almost exactly the same as the initial user sign up process? It's so simple and low-ceremony, it should hardly take the user out of their flow.
It doesn't need to be a whole song-and-dance about having to 'recover' the account on the new device! There's nothing to recover. The user can just log in with a magic link and set up a passkey so that the next login is even easier. That's all!
Obviously, for this UX to work, the app must support being able to store multiple passkeys per account. This is non-negotiable! Passkeys are cheap and easy to store. There's no reason to be overly restrictive here. Once this is supported, you never have to worry about password leaks again. And your users never have to worry about getting phished (in the sense of accidentally entering their credentials into third-party sites).
Prominent security experts agree - passkeys and magic links basically solve the password problem for regular users. We can effectively retire passwords now.
Top comments (4)
It's important to consider the workflow of a user wanting to sign in on a device using which they cannot access their email. For instance, if I'm using my work computer to do something and want to sign in there, but I'm not allowed to access my (personal?) email from my work computer, I cannot click a magic link. A fancier workflow I've seen is that clicking on the magic link enables the requested session to proceed, no matter on what device it was requested.
Most likely, the remedy here is on the user: use a password manager that makes passkeys portable.
This is an extremely bad idea. All a scammer has to do is to convince you to click on the magic link and they can remotely gain access to your account. We absolutely do not want to expose users to this risk. Even technically-minded users can be tricked by putting the right pressure on them.
Forward the magic link from your personal email to your work email, then click on it there.
In this setup, why do users need to deal with Passkeys at all? Isn't this an implementation detail?
Users need to deal with passkeys in this setup because the backend needs signatures that the frontend can provide only by unlocking the passkey. And the passkey can only be unlocked by the user's passkey manager.
But even in this scenario the user may not even need to do anything special. If the user's passkey manager decides that the user has already been securely verified, it can optionally just unlock the passkey without having to force the user to do verification yet again. For the user, it may end up being as simple as 'select my account from the Email input dropdown and I am immediately logged in'.