L’enregistrement vous a donné une clé publique. L’authentification est la preuve que la même clé privée se trouve toujours de l’autre côté.
L’échange
- Votre serveur émet des options de requête : un défi frais, et éventuellement la liste des authentifiants que vous acceptez.
- L’authentificateur signe le défi et les données d’authentificateur.
- Votre serveur vérifie la signature contre la clé publique rangée, et contrôle le défi, l’origine, l’empreinte de la partie utilisatrice et les drapeaux.
Ce qu’il faut ranger, et pourquoi
- L’identifiant d’authentifiant. C’est ainsi que vous retrouvez l’enregistrement quand un authentifiant se présente.
- La clé publique, en forme COSE. Gardez les octets d’origine : réencoder du CBOR casse les signatures.
- Le compteur de signature. Voir plus bas.
- L’identifiant d’utilisateur, pour permettre la connexion sans nom d’utilisateur.
- Un libellé et une date de création, pour que l’utilisateur reconnaisse et révoque un appareil.
Ce dernier point n’est pas cosmétique. Quelqu’un qui perd un ordinateur portable doit retirer le bon authentifiant sans les retirer tous.
Le compteur de signature, traité sainement
Un authentificateur peut incrémenter un compteur à chaque usage, pour qu’un serveur repère une clé clonée : une valeur inférieure à celle rangée signifie que deux exemplaires existent.
Les passkeys synchronisées annoncent en général zéro et ne bougent jamais. Traitez un compteur à zéro comme « non pris en charge », pas comme une alarme, sans quoi vous bloquerez la majorité de vos utilisateurs. N’appliquez le contrôle que lorsque la valeur rangée est déjà non nulle.
L’interface conditionnelle
Plutôt qu’un bouton « se connecter avec une passkey », le navigateur peut proposer l’authentifiant dans le champ de connexion lui-même, aux côtés des mots de passe enregistrés. Cela demande des authentifiants découvrables, alors demandez residentKey: preferred à l’enregistrement si vous voulez cela plus tard.