Salut,
Je suggère la prise en charge du système Passkeys d’Apple.
Quel est le grand avantage par rapport à Discourse Apple Authentication ?
2 « J'aime »
Cependant, dans le cadre des implémentations précédentes, les utilisateurs devaient se connecter à chaque site Web ou application sur chaque appareil avant de pouvoir utiliser la fonctionnalité sans mot de passe. Avec cet engagement élargi, les utilisateurs pourront accéder automatiquement à leur clé d’accès sur plusieurs de leurs appareils, même nouveaux, sans avoir à réinscrire chaque compte. De plus, les utilisateurs pourront utiliser l’authentification FIDO sur leur appareil mobile pour se connecter à une application ou à un site Web sur un appareil voisin, quelle que soit la plateforme du système d’exploitation ou le navigateur qu’ils utilisent.
Je suppose que c’est juste un protocole affiné. Je suis sûr que nous y parviendrons à l’approche de la nouvelle version d’iOS.
4 « J'aime »
[quote=“The Dark Wizard, post:1, topic:229259, full:true, username:TheDarkWizard”]
Salut,
Je suggère la prise en charge du système Passkeys d’Apple.
https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys
[/quote]Je ne savais pas que CDCK devait implémenter cela eux-mêmes. Je pensais que cela dépendait du navigateur Web ou du système d’exploitation ?
Et pour être clair, les passkeys ne sont pas une norme créée par Apple. Elles ont été créées par la FIDO Alliance. Apple n’est qu’une des nombreuses entreprises qui adoptent cette norme.
[quote=“Robert, post:2, topic:229259, full:true, username:merefield”]
Quel est le grand avantage par rapport au plugin Sign in with Apple ?
[/quote]Les passkeys ne sont pas une forme d’authentification unique (SSO).
[quote=“Sam Saffron, post:3, topic:229259, username:sam”]
Je suppose que c’est juste un protocole affiné. Je suis sûr que nous y parviendrons à l’approche de la nouvelle version d’iOS.
[/quote]L’implémentation d’Apple semblait beaucoup plus différente et intéressante, mais peut-être ai-je mal interprété quelque chose lors de la présentation… 
J’ai hâte de voir comment cela évoluera une fois qu’Apple aura publié ses nouvelles versions de systèmes d’exploitation.
1 « J'aime »
Implique-t-il une cryptographie à clé publique/privée ?
Je suis toujours méfiant lorsque Apple est impliqué car ils aiment créer des systèmes propriétaires pour vous maintenir dans leur écosystème…
2 « J'aime »
Il est censé être basé sur une norme ouverte de la Fido Alliance. Google, Microsoft et d’autres plateformes majeures sont également de la partie.
Apple affirme sur son site que cela fonctionnera avec des appareils non-Apple, mais ne donne aucune explication sur la manière dont ils y parviendront.
2 « J'aime »
Censé fonctionner uniquement sur vos appareils.
Heureusement, ce n’est pas le cas. C’est une norme ouverte. 
Apple ne saura pas comment Microsoft et Google l’implémentent avant qu’ils ne le fassent.
1 « J'aime »
Comme discuté, les passkeys ne sont pas un système propre à Apple. Ce ne sont même pas des noms propres.
Les passkeys sont en fait déjà prises en charge par Discourse, bien qu’imparfaitement : elles prennent la forme de clés de sécurité WebAuthn. Le seul changement que Discourse doit apporter pour les prendre en charge correctement est de permettre l’utilisation d’une clé de sécurité au lieu d’un mot de passe, plutôt que comme forme d’authentification à deux facteurs.
Apple a une vidéo sur la façon d’implémenter l’UX, et je suis sûr que de nombreuses autres entreprises le font aussi, mais je résumerai les points pertinents ici.
Pour implémenter une prise en charge parfaite des passkeys (ci-après dénommées « clés de sécurité enregistrées »), Discourse n’a besoin d’apporter que les modifications suivantes :
- Modifier la fenêtre modale de connexion pour n’afficher le champ du mot de passe que si l’utilisateur saisit l’adresse e-mail d’un compte sans clés de sécurité enregistrées. Les passkeys doivent être présentées par défaut, pas les mots de passe. Si l’utilisateur a les deux, considérez le mot de passe comme une option de secours : étant donné que les passkeys disposent d’un système d’authentification d’autres appareils, la seule raison d’utiliser un mot de passe serait si le navigateur est trop ancien pour implémenter la prise en charge des passkeys. Cela deviendra de plus en plus rare.
- Accepter une clé de sécurité enregistrée comme seule source d’authentification : ne pas demander de mot de passe, n’utiliser aucune méthode d’authentification multifacteur. Il est inutile d’exiger un code TOTP, car quiconque possède la clé privée WebAuthn posséderait également le secret partagé TOTP utilisé pour générer des codes à usage unique. Ce dernier est en fait beaucoup plus facile à voler, car il est généré par l’instance Discourse en premier lieu : c’est un secret partagé.
- Permettre aux utilisateurs disposant de clés de sécurité enregistrées de supprimer leurs mots de passe.
- N’utiliser les méthodes d’authentification à deux facteurs que si l’utilisateur utilise un mot de passe.
Cela a été couvert dans notre spécification originale pour webauthn
Cependant, nous n’avons implémenté que la première méthode webauthn, la plus courante.
Eh bien, le premier facteur WebAuthn s’appelle maintenant « passkeys », et il est temps de commencer à y réfléchir.
Pour illustrer qu’il s’agit de la même chose, voici à quoi ressemble actuellement la connexion à l’instance Discourse de Tor Project via Safari sous iOS 16, une fois que j’ai saisi une adresse e-mail et un mot de passe :
1 « J'aime »
Et dans Safari sur macOS Monterey (qui a un an de plus), en utilisant la même clé :
Je soupçonne que macOS Ventura changera la langue pour correspondre à iOS 16.
C’est la principale innovation par rapport à WebAuthn existant du point de vue de l’utilisateur, d’ailleurs : vous pouvez synchroniser la clé privée à l’aide d’un gestionnaire de mots de passe chiffré de bout en bout de votre choix.
3 « J'aime »
Cela fait bien 3-4 mois maintenant, n’est-ce pas ? Alors activer le support du premier facteur pourrait être une chose ?
Je suis d’accord pour ajouter cela comme option d’administrateur facultative, mais je ne pense pas que nous ayons la bande passante pour travailler sur cela pendant un mois ou deux.
1 « J'aime »
Quelqu’un serait-il prêt à financer cela dans Marketplace ?
Arrive également sur Android
3 « J'aime »
Je suis prêt à parier que l’implémentation de Microsoft se retrouvera dans Windows d’ici la fin de l’année.
1 « J'aime »
Une fois que nous aurons le support Android et iOS, je pense que ce sera un mandat clair pour l’implémenter pour Discourse… puisqu’il a été lancé du côté d’Apple, nous attendons maintenant Android.
Deux fonctionnalités sont annoncées aujourd’hui pour les premiers adoptants qui s’inscrivent à la bêta des services Google Play et utilisent Chrome Canary, avec un lancement stable prévu « plus tard cette année » :
L’article a été écrit ce mois-ci, donc il pourrait être lancé d’ici la fin de 2022 ?
7 « J'aime »
Mise à jour
- Les passkeys sont maintenant stables sur Chromium. (Remarque : Firefox ne prend pas encore en charge les passkeys)
- Les gestionnaires de mots de passe comme Dashlane, 1password ont annoncé la prise en charge des passkeys
Voici à quoi ressemble la prise en charge des passkeys au 11 décembre.
source : Passkey support on Android and Chrome | Passkeys | Google for Developers
2 « J'aime »
De plus, il y a une super vidéo de démonstration sur le site https://www.passwordless.dev/
4 « J'aime »
Je pense qu’Android prend désormais en charge les passkeys.