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 thi...
For further actions, you may consider blocking this person and/or reporting abuse
Wow I had the exact same ideas with you (apart from the Conditional UI which I didn't know about - thanks!) and I made magicentry.rs!
An OIDC targeted for self-hosters which has only 2 ways to log in: magic links and passkeys. that's it.
It uses a static YAML config for everything and uses a tiny integrated DB to keep track of sessions. It has "good enough" k8s integration though I want to expand it a bit. It's written in Rust and I use it daily!
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.
That still doesn't solve the issue of logging in to your e-reader or smart TV that don't have email access (and shouldn't have email access).
Obviously, auth methods are not suitable for every device and form factor. I recognize that some devices shouldn't have email access. These devices will need to use other methods, like QR codes or tokens. And they are doing this successfully now.
If you look at the vast majority of auth scenarios now, it's logging in to webapps, which can be handled just fine by passkeys with a magic link email fallback.
No, those devices need other methods, like passwords. And they are doing this successfully now and they have been doing so for decades.
If by 'successfully' you mean 'The amount of phishing today is higher than it has ever been'.
By successful, I mean signing people in without any fuss or nonsense.
Phishing is not a password problem. It is a "Google, Microsoft and other Big Tech companies can no longer be bothered to protect people from phishing."-problem
This is not just wrong, it's on a completely different level of wrong. These big service providers are highly incentivized to protect their users from phishing. Do you think they like having to support users who constantly get phished and locked out of their accounts? That they are not trying their utmost to prevent it? That they are pushing for new phishing-resistant auth methods like passkeys exactly because of this problem?
You realize you are talking out of both sides of your mouth, right? First you accuse them of not doing anything to protect their users from phishing, then you accuse them of doing too much by asking people to use passkeys instead of passwords?
No. Password managers should not be hijacked to deal with passkeys. If passkeys need to be portable, then the people who are promoting them need to build their own passkey managers.
So now you suddenly have to enable e-readers and smartwatches and all other sorts of tech to read email just to be able to log in instead of just allowing the user to set a password and not overcomplicating the devices themselves.
When will developers finally stop promoting passkeys and just get on with it and just offer users the passwords they need? All those articles pushing passkeys are getting old fast and if I had wanted to use passkeys, I would have done so already. Fact is, they are not suitable for purpose and I will not use them until that issue is resolved and the standards are no longer controlled by FIDO or any of its members.
I am fairly sure you know that passwords and OTPs are super easy to phish. There are nowadays easy to use AiTM toolkits that set up reverse proxies with legitimate-looking fake login pages to collect credentials. Passwords and OTPs have essentially failed as an auth mechanism. Phishing account takeovers are worse now than they have ever been. Passkeys offer a solution to this problem. This is why they will have broader uptake, in many cases encouraged by government regulations as well.
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'.