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.
I would if I could use them. But no, Windows refuses to connect to Android, it times out. Same thing on Linux. Android itself? Your encrypted data is locked on this device, and following the help article doesn't do anything. Three different platforms, none with functional passkey support. Awesome UX. My grandparents would've thrown their phone out of the window by now if a website they need to visit requires passkeys. And no, before you ask, Bluetooth is working just fine. I regularly send files between my computers and my phone via Bluetooth, that's not the problem.
https://passkeys.directory/ indicates that plenty of relying parties have implemented support for passkeys and I’ve yet to hear about any efforts taking 100 sprints (if TFA is to be believed that it’s 100x harder than a single sprint’s worth of work). Indeed a rather lazy exaggeration.
Our blog is full of examples of implementation analysis, and we have not encountered one implementation that is bug-free or leverages the complete toolset (same for us: we have just identified a bug in our implementation that relates to WebKit's user-gesture requirements on iOS versions before 17.4). That's not because of them being sloppy, it's just very difficult to get it right; that's exactly the point. For example, Uber and Amazon both did not get it right (until today). Of course, it is possible to implement passkeys without any external resources, and to be honest, we appreciate any effort, be it open-source, tutorials, or commercial applications. If you have been on an authentication team in a big B2C company and truly want to retain the trust of your customers, then you appreciate passkeys immediately as they solve one of the biggest problems... So we are also happy to see a half-good implementation as it improves security.
> 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.
It's funny but that's almost exactly what #15 in the article even eventually states that you can't ignore passkeys because users love them and they will be ubiquitous very soon and also that the article isn't meant to alarmist "it's all too hard" but cautionary "have you considered x?" but they knew writing it will sound alarmist (because of course they wrote some parts of it in an alarmist tone for clickbait/salesbait). Of course #15 ends with trying to sell their product.
We tried to make the article fun to read. In the end, we could have omitted our hint about our product, but honestly, we have gathered a lot of know-how there for anyone who wants to build passkeys on their own. Our blog and this article are one of the better resources to start with, and even without it, our product offering is obvious. But: We are very commited to help anyone implementing passkeys.
We use email or phone number as the identifier. We recommend verifying on sign-up, but it is actually a configuration option. We have other customers who want to request OTP on the next sign-in. Not validating the identifier on sign-up comes with a long list of potential security/ux race conditions further down the chain (especially if you also support social logins). What is your approach?
Yes, we use email as the identifier, and yes we verify on signup.
We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.
A weekend project is probably fine -- I wrote a Passkey-based SAML IdP in a weekend (re-using the SAML IdP from a different project). It's written in Tcl.
The hardest part of dealing with the Passkeys was remembering to read the whole specification before implementing it -- I spent a lot of time parsing their CBOR/COSE-based specification so that I could get the public key before "discovering" that there was a method for that defined by the specification.
You must know something about the domain. One time I spent several weeks falling to implement a minimal SAML relying party. Not even an idp. I found the spec to be impenetrable without a baseline understanding of the jargon. All the definitions seemed to be circular like when I end up on a Wikipedia article for some fancy math concept.
It's been a while, but I read through the OASIS spec for SAML for my implementation. There is a lot of yak shaving and I also had to implement XML Digital Signatures (XML-DS), and XML Canonicalization (C14N), but overall I don't think it took too long for something that worked, and was a library so I could just give it a key (or PKCS#11 handle) an identity and get back a SAML Assertion, which is fundamentally what I was after. It's available for viewing here [0].
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.