

Passkeys est génial! Juste une paire de clés publique / privée que vous pouvez utiliser pour vous authentifier avec un site Web (ou une application associée).
Ils sont beaucoup plus pratiques que les mots de passe car vous n'avez pas à vous souvenir de quoi que ce soit, ou à choisir quelque chose qui satisfait des règles de plus en plus complexes. Ils sont également plus sûrs car ils sont liés au site avec lequel vous vous authentifiez, potentiellement éliminer le phishing, et seule une clé publique est stockée sur le serveur, donc il n'y a rien qui vaut la peine de voler (la clé publique est, vous l'avez deviné, public).
La clé privée est gardée par vous. Ou plutôt, votre gestionnaire de mots de passe, il peut donc être partagé entre les appareils. Apple, Google, Microsoft et Amazon encouragent activement l'adoption. Si vous stockez une clé de passe dans un gestionnaire de mots de passe (tel que Dashlane, 1Password ou Apple Keychain), vous pouvez également le partager avec des amis.
L'inscription et la connexion sur les sites Web et les applications et les applications ont jusqu'à présent été une énorme barrière, mais avec Passkeys, il est finalement résolu. Implémentons-les partout afin que nous puissions enfin consulter des mots de passe au bac. Passkeys est plus facile et plus sûr - qu'est-ce qui ne va pas aimer?
Chez Red Badger, nous maintenons la boîte à outils de développement d'applications multiplateforme open source appelée Crux. Il utilise Rust et WebAssembly pour faciliter la création d'applications faciles à créer sur iOS, Android et Web (et ligne de commande, et les applications Terminal, et ...).
Crux nous permet de créer une fois la fonctionnalité de notre application et de le tester en millisecondes, ce qui nous permet de s'assurer que notre application fonctionne correctement, et exactement de la même manière, sur toutes les plateformes.
Ce repo consiste à apporter des applications Passkeys à Crux.
Ce n'est pas massivement compliqué de le faire, mais il y a quelques étapes pour l'enregistrement et la connexion que vous devez bien faire. Il est un peu difficile de l'ajouter aux applications Web existantes (et aux applications iOS et aux applications Android) et à vous assurer que l'implémentation est correcte sur les trois. Crux aide ici. Nous pouvons simplement le construire et le tester une fois.
Le répertoire shared de ce dépôt contient une capacité Crux Passkey, qui, avec la capacité crux_http , est orchestrée par une application Crux Auth, avec des tests, qui peuvent être utilisés comme "sous-application" - imbriquées dans une autre application Crux.
Mon plan était génial - réunir une technologie vraiment cool comme Passkeys, Rust, Webassembly et Crux - mais j'en voulais plus.
J'ai donc ajouté Fermyon Spin dans l'équation. Le rotation est super! Il est sans serveur sans le démarrage à froid. Les services ultra légers qui sont lancés en réponse à une demande entrante (en microsecondes) et meurent après la demande de demande.
Pour soutenir PassKeys, nous avons besoin d'un backend qui expose le protocole WebAuthn. Il est écrit en rouille et compilé sur WebAssembly ( wasm32-wasi ). J'ai dû sauter à travers quelques cerceaux, comme le vendeur d'une version compatible WasM d'OpenSSL - nous sommes sur le bord de saignement ici - mais cela fonctionne!.
Le serveur héberge également une application Web Leptos écrite en rouille.
Il peut être déployé, en ce qui concerne le cloud Fermyon.
Passez au répertoire crux-passkey-server :
cd crux-passkey-server Créez un fichier .env avec le contenu suivant:
export SPIN_VARIABLE_DOMAIN_LOCAL=localhost
export SPIN_VARIABLE_DOMAIN_REMOTE=crux-passkey-server-8sdh7f6w.fermyon.app # Change this to your own domain Créez un certificat SSL (de préférence émis par un CA de confiance) et saisissez-les et placez-les dans le répertoire certs . Les noms de fichiers doivent être cert.pem et key.pem . Vous pouvez suivre les instructions ici (vous devrez peut-être ajouter le CA au magasin de confiance de votre navigateur - ou leur faire confiance dans le trousseau sur macOS - Spin 2.0 se bloque sur l'utilisation de certificats auto-signés)
Démarrez le serveur de spin local:
./run.shPuis ouvrez votre navigateur sur https: // localhost
Ou publier sur Fermyon Cloud (vous devrez avoir un compte Fermyon et avez installé la CLI Fermyon):
./cloud_create_db.sh # Only need to do this once
./deploy.shPuis ouvrez votre navigateur sur https://crux-Spasskey-server-8sdh7f6w.fermyon.app (ou quel que soit votre domaine)

Le diagramme ci-dessus montre le processus d'enregistrement.
L'utilisateur entre dans leur adresse e-mail et clique sur "Register" (Web) ou "Inscrivez-vous" (application iOS).
L'application auth , via l'événement GetCreationChallenge et la capacité crux_http , envoie une demande POST au backend.
Le backend répond avec un objet PublicKeyCredentialCreationOptions , via l'événement CreationChallenge .
Pour l'application iOS, cela est passé, via la capacité passkey , du côté iOS-Shell de l'implémentation de la capacité passkey , qui utilise un ASAuthorizationController pour inviter l'utilisateur à créer une clé de passe.
Pour le shell Web, cela est passé, via la capacité passkey , à la méthode navigator.credentials.create du navigateur par le côté Web de l'implémentation de la capacité passkey , qui invite l'utilisateur à créer une clé passante.
L'utilisateur crée une clé de pass et la capacité passkey renvoie un objet RegisterPublicKeyCredential , via l'événement RegisterCredential , qui contient la clé publique, le défi signé et d'autres informations.
L'événement RequestCredential est géré par l'application, envoyant une demande POST , via la capacité crux_http , au backend avec l'objet RegisterPublicKeyCredential .
Le backend vérifie les informations et enregistre l'utilisateur en stockant la clé publique de l'utilisateur dans sa base de données, répondant avec un code d'état 201 Created .
L'événement CredentialRegistered est géré par l'application, qui met à jour son état pour indiquer que l'utilisateur est enregistré.

L'utilisateur entre dans leur adresse e-mail et clique sur "Connexion" (Web) ou "Connexion" (application iOS).
L'application auth , via l'événement GetRequestChallenge et la capacité crux_http , envoie une demande POST au backend.
Le backend répond avec un objet PublicKeyCredentialRequestOptions , via l'événement RequestChallenge .
Pour l'application iOS, ceci est passé, via la capacité passkey , du côté iOS-Shell de l'implémentation de la capacité passkey , qui utilise un ASAuthorizationController pour inciter l'utilisateur à se connecter avec leur clé de passe.
Pour le shell Web, cela est passé, via la capacité passkey , à la méthode navigator.credentials.get par le côté Web de l'implémentation de la capacité passkey , qui incite l'utilisateur à se connecter avec leur clé de passe.
L'utilisateur entre dans leur clé de pass et la capacité passkey renvoie un objet PublicKeyCredential , via l'événement Credential , qui contient le défi signé et d'autres informations.
L'événement RequestCredential est géré par l'application, envoyant une demande POST , via la capacité crux_http , au backend avec l'objet PublicKeyCredential .
Le backend vérifie les informations et répond par un code d'état de 200 OK .
L'événement CredentialVerified est géré par l'application, qui met à jour son état pour indiquer que l'utilisateur est connecté.
Le répertoire shared contient le cœur de la mise en œuvre. C'est un exemple d'une application Root Crux qui niche une application auth Crux. L'application auth orchestre les capacités crux_http et passkey pour fournir des fonctionnalités d'enregistrement et de connexion Passkey contre le backend.