Support for passwordless flows via WebAuth was only added to browsers very recently. And it was only with the introduction of Passkeys that the user experience became good enough for regular people to use. Now the keys will auto-sync between devices and can be shared with other people via Bluetooth, etc. It’s too early to say it won’t be well understood or adopted.
> Multi-devicing for authentication is a poor user experience. Even having to go click a link in your mailbox sucks.
Agreed. Passkeys reduce this friction quite a bit since you won’t need to multi-device if you’re already signed in to your platform account. But if you’re borrowing someone else’s computer, then yeah you need to get a key from another device that already has it. If this use case happens to you a lot, I would recommend using a USB security key to store your credentials.
> People don't have their phone on them all the time (and some don't even have a smartphone).
WebAuthn doesn’t require a phone. It only requires you to be using or have handy some device that holds your keys. It can be a laptop or a USB security key. Again, I would recommend a USB security key for people who don’t own a phone or computer. These things are cheap enough for charities to give them out in large numbers and small enough to go anywhere. Keep one on your keychain. If that’s still too much of a problem, then keep your keys in your platform account and see if you can temporarily sign in to your platform account on the device where you are a guest. Just be sure to sign out afterward.
> New users don't understand these methods of authentication.
An old dog can learn new tricks, but it takes time. We’re in a phase where most of the writing on this topic is geared towards developers. That will change. A lot of people seem to prefer native UIs to web based UIs and WebAuthn makes a large part of the sign in process native, so maybe people will find it easier. I certainly do with the implementations I’ve built, though that may be a given.
> They're generally much more complicated to implement than a basic email/password combo.
Agreed and I think this is mostly the fault of the spec. For example, some of the data the client and server have to send to each other can’t be easily serialized to JSON and for some reason, apparently no one thought that was a problem. There are some ways to do it but they are hacky and the auth libraries barely even paper over this problem.
Also, the spec wants a signature counter to be implemented to prevent replay attacks. But Apple’s implementation of Passkeys always reports 0 for the signature count, which I think may be to preserve privacy. I don’t particularly like having to store the signature count either, nor does it seem like a reliable detection method, so Apple’s approach seems ok to me. But then how do I prevent replay attacks? There’s very little information on this subject, let alone guidance on how to handle it.
There’s lots of jargon in the spec that you have to memorize and the libraries that exist today tend to embrace the same jargon.
I think a lot of these wrinkles will be ironed out in time. The momentum is clearly there and the tech has gotten to a point where you can build some really low friction sign in flows. You may bang your head against the wall dealing with some of the wrinkles I mentioned, but the end result can be great. One of my favorite features is that you can build the sign in flow in such a way where the native UI presents the accounts that are available. That means not only does the user not need to type a password, but they don’t need to type their email either. Literally no more typos possible, even for people who don’t use autofill.