Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts.
My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-)
[1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
These crop up every now and again but they never address my biggest concern, which how we can be sure that https://w3c.github.io/webauthn/#attestation-object will not create a situation where only approved devices are allowed to authenticate.
It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.
This thread is a great survey of why the passkey roll out is so controversial. Even without the inevitable “but what if Google/Apple permabans me?” thread, we have confusion about whether QR codes are sufficient, biometrics are necessary, and a baffling UI that maybe means to say “debug the bluetooth stacks on whatever devices are nearby”.
Very thorough article, nice! I'll add some other pain points I experienced:
- You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess.
- The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!]
- I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now.
[1]: https://github.com/passkeydeveloper/passkey-authenticator-aa...
There have been times in the past where we took something moderately simple (random number generation once you've got a good entropy source; digital signatures) and turned them into a monster (Dual-EC DRBG; ECDSA). It turns out those were bad ideas.
The more I read about passkeys, the more I feel we're creating a new monster here. I'm just glad there's no "alg:none" option included.
If you have a device that can store and sign with resident keys for a private/public key infrastructure, I don't see why we need all the extra complexity unless you want to charge everyone $4.99/mo for a key management SaaS, or force the last remaining Win11 users who log in with a local account onto Microsoft Accounts and Windows Hello (which I understand is the only way to get passkeys in edge without third-party software or devices).
About three weeks ago, I grabbed some samples out of a freezer at -80C without gloves because it was quick. Yes it was stupid! (It's also quite common that someone who needs to "grab one sample real quick" does this.) The fingers on my right hand felt prickly for a couple minutes after that but no harm, it seemed. Well it took a couple weeks but the fingertips on my right hand all started blistering and one finger basically has a second-degree burn. My left hand, which I didn't use on the freezer, seems to be experiencing mirroring blisters, and I have no explanation since I didn't do anything (stupid or otherwise) to burn/blister them. If I were relying on passkeys and I couldn't register multiple keys, like one for each of my ten fingers plus face plus hardware token, I'd be locked out of my passkey-protected accounts for... I mean I honestly don't know how long, my fingerprints could still be healing a month from now.
So between that and the kinks that still need to be worked out regarding exporting and FAANG lock-in, I'll keep using my passwords. And wearing gloves when using -80C freezers.
I still haven’t really migrated to passkeys yet. Until Bitwarden on iOS properly supports them I won’t fully switch. I don’t want to have to manage a passkey on every device. So I will wait until I can sync between all my devices.
But when I did play with them a bit it seemed so full of weird pitfalls. Aren’t I supposed to be able to use my phones passkey to login on my PC with a QR code? I never got that to work. The article implies that might be a windows 10 vs 11 issue- but why? It’s a QR code. Windows 10 should be capable of displaying a QR code. I tried it just now. Windows pulls up a “making sure it’s you” box, with no buttons other than cancel, and no option to use the passkey from elsewhere. This computer doesn’t have a passkey, what is windows doing?
Conflict of interest coming from a company selling passkey implementation.
I'm honestly bamboozled why anyone gives passkeys the time of day, given the mess that is attestation and its ability to enforce user-hostile ecosystem lockin:
https://github.com/keepassxreboot/keepassxc/issues/10407
https://news.ycombinator.com/item?id=39698502
https://news.ycombinator.com/item?id=39706876
In principle, it's a great idea. This specific implementation should be treated as DoA because of how attestation works.
I tried out making a passkey on passkeys.io just now. On an Android phone, up-to-date OS, Bitwarden set as the preferred password manager, the "create a passkey" button, when tapped, switches to a loading spinner very breifly, then resets. Nothing else happens. I guess I'm not going to be using any passkeys.
I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.
Two assumptions I have, and I'd love for people to shoot me down on this:
1. Most applications will get "Passkey" support by dint of OIDC SSO support; OIDC IdPs are the things that will implement Passkeys (SIWA and SIWG for "retail" users).
2. Direct Passkey adoption in applications will round towards zero, maybe excepting huge applications like Insta; people will do Passkeys with their Google account, but not with (say) Doordash.
If those premises hold, I probably don't need to be sold (though this post is helpful and incredibly detailed) on why not to do my own direct implementation of Passkeys; it makes more sense for us to nail OIDC.
Fear, uncertainty and doubt is the sword Corbado wants to live by, so it's the sword it should die by. You shouldn't trust Corbado with your users because the risk is too high and there are much more trusted solutions such as Auth0. Its implementation of passkeys is much more user-friendly. It doesn't require users to enter their email address. On my Mac, for example, it's one click, one fingerprint, then I'm in.
Passwords may not be ideal but I will always take them (with 2FA/YK) over passkeys... the latter is just asking for trouble :/
Would it not be best if Passkey authorization was implemented as a service, so that not everybody have to re-implement the same thing?
Behind the scenes, 10+ companies are working on passkey export / import
Great write up though, thanks for this
Dumb question: are passkeys essential a “login token” (binded to a device)?
tldr; It's still a giant mess, and until browser developers get around to fixing it, it's probably better to punt on Passkeys for now.
The question is, can the mess get fixed enough before developers like me give up and move on to something else. I gave up a while ago, figured I'd check back in a few years. My current guess: I'll never have to implement them.
The issues the article raises are real, but it paints passkey implementation as much harder than it actually is. It's in Corbado's interests to exaggerate the difficulties.
We added passkeys to existing password authentication for a python flask app, and it took about 40 hours. 20 hours to get basic registration/authentication working, and another 20 hours to tweak the UX (things like popping up a "Want to use passkeys?" dialog occasionally, a passkeys page so users can manage them - all huge problems according to the article).
So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.