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.
100% That is exactly how it is playing out. People do not register (2passkeys * 20 services). They sign in with Google or Microsoft and call it a day. Privacy implications ignored.
Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.
I would assume apps that are non-geek oriented will do quicker adoption. In my experience, many people are looking at passkey like a
- Password manager that is automatically working fine on their phone
- Apple or Google takes care of everything. And users think of it like 'Sign in with Google/Apple equivalent'. Press fingerprint/face-ID and all just works.
Only PITA I expect is that banks type dinosaurs will screw up this (like they did with 2FA - with custom apps and non-standard implementations). I wish W3C would some way ban these but banks are somehow escaping standards.
What you're saying mostly makes sense to me, but there's one big edge-case that I care about.
For my own applications I like to have my staff-level admin access work independently of external providers. I don't want to run into a situation where my Google account (or some other SSO service) has been accidentally banned by a weird machine learning algorithm hiccup and now I can't sign into my own service's dashboard to sort out problems.
Admin accounts are also exactly the kind of thing that I want to have my own 2FA for - so passkeys are ideal for them.
So yeah, Passkeys for retail users is something I'll outsource to an IdP, but I'm still very interested in them for my own "staff-level" administrative accounts.
Yeah that’s a break glass account situation. Even with a self hosted IdP solution, it going down isn’t going to perform the OIDC SSO dance to get into whatever service so having that backup account or fallback authentication access is important.
Disclaimer: Co-Founder Corbado here. B2C Auth is much harder than people think. Consumers are unforgiving when it comes to UX. Big Tech sets the bar pretty high for what consumer experience should be. In B2B or B2E authentication, the UX is often horrible, but there is no choice for the user. He has to log in. On e-commerce sites, there are plenty of alternatives. At the same time, protecting customers becomes increasingly difficult; they just reuse passwords or lose them somehow. We think consumers will demand "Face-ID Login for the Web" (consumer simplification), which, from their point of view, is very simple. Even simpler than Social Login.
OIDC implementations for consumers are often not good enough; we have seen other companies promote them for Passkeys. We think that can be suitable for B2B-Auth but not for B2C
It is difficult to say, but there are some reservations people have because sometimes they are not sure what exactly happens with social login, or they have one Google Account associated with the wrong email, and they do not want to use it. Google Social is particularly strong on Android, of course, but in general, there have been different numbers published ranging from a 15-65% take rate depending on the product, the target group (age), and how strongly it is positioned within the product. In our own numbers, we can see that when offered social in parallel to passkeys, 30-40% go with social sign-up but much less for login when a passkey is added (of course, on our page, there is a heavy early adopter skew pro passkeys).
Yes, I agree. We still have passwords although Social Logins have existed for years. And Passkeys are also adopted because they increase security from a 2FA perspective.
2. means having your Google Account blocked locks you out of every other site, thus i will not use passkeys on sites that require login through Google.
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.