Hi,
I’m suggesting support for Apple’s Passkeys system.
What’s the big leap over Discourse Apple Authentication?
2 Likes
However, under previous implementations, users have to sign into each website or app with each device before they can use passwordless functionality. With this extended commitment, users will be able to automatically access their passkey on many of their devices, even new ones, without having to re-enroll every account. Additionally, people will be able to use FIDO authentication on their mobile device to sign into an app or website on a nearby device, regardless of the OS platform or browser they’re running.
I guess it is just a refined protocol. I am sure we will get to it closer to the new ios release.
4 Likes
I didn’t realize that this is something that CDCK has to implement themselves. I thought it was dependent on the web browser or operating system?
And just to be clear, passkeys aren’t a standard made by Apple. They were made by the FIDO Alliance. Apple is just one of many companies that’s adopting the standard.
Passkeys aren’t a form of SSO.
Apple’s implementation seemed much more different and interesting, but maybe I misinterpreted something during the keynote… 
I’m excited to see how this develops once Apple releases its new operating system versions.
1 Like
Involving a kind public/private key cryptography?
I’m always wary when Apple is involved because they love to create proprietary schemes to keep you stuck in their ecosystem …
2 Likes
It’s supposed to be based on an open standard by the fido alliance. Google, Microsoft, and other major platforms are also on board.
Apple claims on its site that it will work with non-apple devices but gives no explanation on how they will accomplish that.
2 Likes
It’s supposed to only work on your devices.
Thankfully, this isn’t it. It’s an open standard. 
Apple won’t know how Microsoft and Google implement it until they do so.
1 Like
As discussed, passkeys are not Apple’s own system. They aren’t even a proper noun.
Passkeys are actually already supported by Discourse, albeit imperfectly: they take the form of WebAuthn security keys. The only change Discourse needs to make to support them properly is allowing a security key to be used instead of a password, rather than as a form of two-factor authentication.
Apple has a video about how to implement the UX, and I’m sure many other companies do too, but I’ll summarize the relevant points here.
To implement perfect support for passkeys (hereafter referred to as “registered security keys”), Discourse only needs to make the following changes:
- Change the sign-in modal to only show the password field if the user enters the email address of an account without registered security keys. Passkeys should be presented as the default, not passwords. If the user has both, treat the password as a backup option: since passkeys have a system for authenticating other devices, the only reason you’d use a password is if the browser is too old to implement passkey support at all. This will become increasingly uncommon.
- Accept a registered security key as the sole source of authentication: do not prompt for a password, do not use any multi-factor authentication methods. There is no point requiring a TOTP code, as anyone with the WebAuthn private key would also have the TOTP shared secret used to generate one-time codes. The latter is actually much easier to steal, as it is generated by the Discourse instance in the first place: it’s a shared secret.
- Allow users with registered security keys to remove their passwords.
- Only use two-factor authentication methods if the user uses a password.
That was covered in our original spec for webauthn
However we only implemented the first, and most common webauthn method.
Well, first factor WebAuthn is called “passkeys” now, and it’s time to start considering this.
To illustrate that they are the same thing, this is what logging into Tor Project’s Discourse instance through Safari currently looks like in iOS 16, once I’ve entered an email and password:
1 Like
And in Safari on macOS Monterey (which is a year older), using the same key:
I suspect macOS Ventura will change the language to match iOS 16.
That’s the main innovation over existing WebAuthn from the user’s perspective, by the way: you can synchronize the private key using an end-to-end encrypted password manager of your choice.
3 Likes
It’s been well over 3-4 months by now, hasn’t it? So enabling first factor support could be a thing?
I am ok to add this as an opt in admin option, but do not think we have bandwidth to work on this for a month or 2
1 Like
Would somebody be willing to fund it in marketplace?
Coming to Android too
3 Likes
I’d be willing to bet that Microsoft’s implementation will find its way into Windows by the end of the year.
1 Like
Once we have Android and iOS support, I think that is a clear mandate to implement it for Discourse… since it has shipped on the Apple side we are waiting for Android now.
Two features are being announced today for early adopters that enroll in the Google Play Services beta and use Chrome Canary, with a stable launch coming “later this year”:
The article was written this month, so it might ship by the end of 2022?
7 Likes
Update
- Passkeys are now stable on chromium. (Note: Firefox does not support passkeys yet)
- Password managers like Dashlane, 1password announced support for passkeys
This is what passkeys support looks like as of Dec 11.
source: Поддержка пароля на Android и Chrome | Authentication | Google Developers
2 Likes
Also, there is a cool demo video on the https://www.passwordless.dev/ website
4 Likes
I think android is support passkeys now