Clé résidente WebAuthn : les informations d'identification détectables en tant que passkeys

Les passkeys et le protocole sous-jacent WebAuthn révolutionnent le paysage de l'authentification. Cependant, configurer correctement un serveur WebAuthn peut s'avérer délicat. Les erreurs de configuration peuvent non seulement introduire des vulnérabilités, mais aussi rendre inutilisables les passkeys existants si vous devez les modifier plus tard. Cet article de blog devrait vous aider à mieux comprendre les spécifications souvent complexes de WebAuthn et vous conseiller sur les meilleurs paramètres pour votre cas d'usage.

WebAuthn fonctionne avec trois entités principales :

• La Partie de confiance (Relying Party ou RP) : Il s'agit de votre service web qui souhaite authentifier un utilisateur. Elle envoie des défis au client, vérifie les réponses et gère la clé publique d'un passkey.
• Les authentificateurs : Ce sont des appareils qui peuvent prouver la possession d'une information d'identification. Par exemple, les smartphones, les ordinateurs portables ou les clés de sécurité (comme les YubiKeys). Les authentificateurs peuvent être spécifiques à une plateforme (comme Windows Hello ou Touch ID / Face ID d'Apple) ou multiplateformes (comme les clés de sécurité, par exemple les YubiKeys).
• Les clients : Généralement, ce sont des navigateurs web ou des applications natives qui agissent comme intermédiaires entre la RP et l'authentificateur. Ils facilitent la communication, en s'assurant que les données circulent correctement et en toute sécurité.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Ci-dessous, nous décrivons le flux de données de haut niveau lors d'un processus d'authentification (connexion ou inscription).

1. Initiation par le client : Le processus commence côté client, généralement lorsqu'un utilisateur tente de se connecter ou de s'inscrire. Par exemple, il peut cliquer sur un bouton « Se connecter avec WebAuthn » et le client envoie une demande de défi à la RP.
2. Requête de la RP : La RP envoie alors un défi en retour au client. Ce défi est une valeur générée de manière aléatoire qui garantit l'authenticité de la réponse ultérieure.
3. Du client à l'authentificateur : Lors de l'inscription, le client demande à l'authentificateur de créer un nouveau passkey en générant la paire de clés publique-privée correspondante. Lors de la connexion, le client demande à l'authentificateur de signer le défi. Cela se fait à l'aide de la clé privée sur l'authentificateur, qui correspond à une clé publique précédemment enregistrée et stockée sur la RP.
4. Réponse de l'authentificateur : Lors de l'inscription, l'authentificateur renvoie la clé publique au client. Lors de la connexion, l'authentificateur signe le défi et renvoie cette assertion signée au client.
5. Du client à la RP : Le client transmet cette nouvelle clé publique / l'assertion signée à la RP.
6. Vérification par la RP : La RP stocke la clé publique / vérifie l'assertion signée à l'aide de la clé publique stockée. Si elle est valide, l'authentification est réussie.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Plus de 10 000 développeurs font confiance à Corbado et rendent Internet plus sûr avec les passkeys. Des questions ? Nous avons rédigé plus de 150 articles de blog sur les passkeys.

Rejoindre la communauté Passkeys

Le flux de processus de haut niveau décrit ci-dessus concerne les processus d'inscription et de connexion WebAuthn. Les passkeys sont construits sur WebAuthn. À l'origine, le terme « passkeys » était utilisé comme un terme plus mémorable et moins technique que WebAuthn pour décrire la même chose. De plus, les passkeys offrent plus de fonctionnalités que le standard WebAuthn, par exemple la possibilité de synchroniser les passkeys via des comptes cloud ou des gestionnaires de mots de passe.

Pour mieux comprendre les sections suivantes, nous allons définir quelques termes importants du protocole WebAuthn afin d'avoir une compréhension commune.

• Credential ID : Le Credential ID est un identifiant unique attribué à une information d'identification de clé publique spécifique générée par un authentificateur. Il permet aux Parties de confiance (RP) d'identifier et de sélectionner le bon PublicKeyCredential pour les processus d'authentification.
• PublicKeyCredential : C'est la principale structure de données renvoyée par l'API WebAuthn du navigateur ou des applications natives. Elle englobe à la fois les données d'attestation lors de l'inscription et les données d'assertion lors de la connexion. Essentiellement, elle contient les données dont la RP a besoin pour vérifier le processus.
• Attestation : L'attestation dans le contexte de WebAuthn sert de preuve de l'origine et de l'intégrité de l'authentificateur. Lors de l'inscription, c'est une façon pour l'authentificateur de dire : « J'ai enregistré de manière sécurisée l'information d'identification de l'utilisateur, et voici une déclaration que vous pouvez utiliser pour le vérifier ». La Partie de confiance peut alors vérifier que la signature provient d'un authentificateur spécifique autorisé (par exemple, une YubiKey). Tous les authentificateurs de passkeys ne répondent pas avec une telle attestation ; certains ne renvoient tout simplement pas de données utiles (voir ici la liste des authentificateurs de passkeys). D'autres AAGUID (Authenticator Attestation GUIDs) qui identifient plus d'authentificateurs (principalement des clés de sécurité, par exemple les YubiKeys) peuvent être trouvés dans le service de métadonnées de l'Alliance FIDO.
• Assertion : Après le processus d'inscription, lorsqu'un utilisateur tente de se connecter, l'authentificateur produit une assertion. L'assertion est essentiellement le PublicKeyCredential + le défi signé. Cette assertion prouve que l'utilisateur possède la clé privée liée à la clé publique enregistrée sans révéler la clé privée réelle. C'est la façon pour l'authentificateur de dire : « C'est le véritable utilisateur, et je peux me porter garant pour lui. »

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Les clés résidentes (RK) et les clés non résidentes (NRK) sont deux types de clés cryptographiques utilisées dans le protocole WebAuthn. Elles diffèrent principalement par leur lieu de stockage et leur mécanisme de récupération.

Définition :

Les clés résidentes sont stockées directement sur l'authentificateur lui-même. Il peut s'agir d'une clé de sécurité (par exemple, une YubiKey), d'une enclave sécurisée de plateforme (par exemple, l'enclave sécurisée de l'iPhone) ou d'un module de plateforme de confiance (TPM) sur un ordinateur portable. L'interface utilisateur conditionnelle (remplissage automatique des passkeys) ne fonctionne que pour les clés résidentes, et le groupe de travail WebAuthn exige actuellement que les clés résidentes soient considérées comme des passkeys.

Dans la capture d'écran suivante, vous voyez une liste de toutes les clés résidentes (Credential ID, rpID, nom d'utilisateur, nom d'affichage) qui sont stockées sur une YubiKey. Les clés non résidentes ne figurent pas dans la liste, car elles ne sont pas stockées sur l'authentificateur :

Flux de connexion :

Source : William Brown

Lors du processus de connexion, la Partie de confiance envoie une requête sans spécifier d'informations d'identification au client (navigateur), qui commence à interroger l'authentificateur (ici dans le graphique : clé de sécurité). L'authentificateur découvre toutes les clés résidentes pour la Partie de confiance correspondante et le client (navigateur) sélectionne la clé résidente souhaitée. Cette clé résidente est utilisée pour signer le défi. La signature est envoyée de l'authentificateur via le client à la Partie de confiance.

Avantages :

1. Expérience utilisateur simplifiée : L'un des avantages les plus significatifs des clés résidentes est que l'authentificateur stocke l'identifiant utilisateur (par exemple, e-mail, numéro de téléphone, nom d'utilisateur) et peut donc pré-remplir l'identifiant utilisateur pour la connexion. Les utilisateurs n'ont pas besoin de se souvenir ou de saisir leurs identifiants, ce qui simplifie le processus de connexion, en particulier sur les appareils dotés de capacités biométriques. Cela peut aussi se faire automatiquement avec l'interface utilisateur conditionnelle (Conditional UI).
2. Authentification spécifique à l'appareil : Les clés résidentes peuvent fournir une couche de sécurité supplémentaire en liant l'authentification à un appareil spécifique. Cela peut être particulièrement utile pour les services qui veulent s'assurer que les utilisateurs se connectent depuis des appareils de confiance.
3. Conditional UI (remplissage automatique des passkeys) : L'interface utilisateur conditionnelle ne fonctionne qu'avec les clés résidentes, offrant l'expérience de connexion la plus fluide (voir ci-dessous pour plus de détails).

Inconvénients :

1. Limitation du stockage : Certains authentificateurs ont une capacité de stockage limitée. En particulier pour les clés de sécurité (par exemple, les YubiKeys), il y a souvent une limite au nombre de clés résidentes qu'elles peuvent stocker (la plupart ont une limite allant de 8 à environ 100 clés résidentes). Une fois cette limite atteinte, les anciennes clés peuvent devoir être supprimées pour faire de la place aux nouvelles, ou l'utilisateur peut avoir besoin d'utiliser un autre authentificateur.
2. Perte de l'authentificateur : Si l'authentificateur, par exemple une clé de sécurité (par exemple, une YubiKey) ou un smartphone, est perdu ou endommagé, toutes les clés résidentes sur cet appareil sont perdues. Cela pourrait bloquer l'accès des utilisateurs à plusieurs services jusqu'à ce qu'ils se réinscrivent ou récupèrent leurs comptes. La synchronisation des clés via un compte cloud (par exemple, le trousseau iCloud, le gestionnaire de mots de passe Google) ou un gestionnaire de mots de passe moderne (par exemple, 1Password ou Dashlane) empêche cette perte.
3. Préoccupations de sécurité : Si un authentificateur contenant des clés résidentes est volé, un attaquant pourrait tenter d'extraire les clés. Bien que les authentificateurs modernes disposent de mécanismes de sécurité robustes pour empêcher l'extraction (par exemple, l'utilisateur protège l'appareil avec un code PIN, un mot de passe ou un geste fort), le risque, bien que minime, existe toujours.

Cas d'usage : Idéal pour les appareils où l'utilisateur s'authentifie fréquemment, comme les smartphones personnels ou les ordinateurs portables.

Want to find out how many people use passkeys?

View Adoption Data

Définition :

Les clés non résidentes, en revanche, ne sont pas stockées sur l'authentificateur. Au lieu de cela, l'authentificateur génère une nouvelle paire de clés (basée sur sa clé maîtresse protégée en interne) et envoie la clé publique de cette nouvelle paire de clés au serveur (Partie de confiance) avec le Credential ID (qui contient une graine ou seed) lors de l'inscription. Le serveur associe alors cette clé publique au compte de l'utilisateur. Pour les authentifications ultérieures, l'authentificateur dérive à nouveau la clé privée en recevant le Credential ID, en extrayant la graine et en la combinant avec la clé maîtresse. Parce que la clé n'est disponible que temporairement dans la mémoire protégée de l'authentificateur, elle est parfois appelée clé éphémère en langage cryptographique.

Flux de connexion :

Source : William Brown

Lors du processus de connexion, la Partie de confiance doit d'abord identifier quel utilisateur demande l'authentification (par exemple, en demandant un identifiant utilisateur, comme un e-mail, un numéro de téléphone ou un nom d'utilisateur), puis envoie les Credential IDs qu'elle connaît pour l'utilisateur demandeur au client (navigateur). Le client les transmet à l'authentificateur (ici : clé de sécurité). L'authentificateur utilise le Credential ID avec la clé maîtresse de l'authentificateur pour dériver la clé privée temporaire, signe le défi avec la clé générée et le renvoie au client (ici : navigateur), qui le transmet à la Partie de confiance. Les clés non résidentes étaient initialement utilisées comme deuxième facteur avant l'introduction des passkeys. Par conséquent, l'identification de l'utilisateur en premier lieu faisait partie du processus de connexion normal.

Avantages :

1. Évolutivité : Comme les clés non résidentes ne se trouvent pas sur l'authentificateur, les utilisateurs peuvent avoir un nombre presque illimité de clés non résidentes associées à divers services. C'est particulièrement avantageux pour les utilisateurs qui ont des comptes sur de nombreuses plateformes.
2. Capacité d'itinérance : Les clés non résidentes sont idéales pour les authentificateurs itinérants comme les clés de sécurité (par exemple, YubiKey). Un utilisateur peut utiliser la même clé de sécurité (par exemple, YubiKey) pour s'authentifier sur plusieurs appareils et plateformes, offrant une expérience cohérente.
3. Dépendance réduite au stockage de l'authentificateur : Avec des paramètres de serveur WebAuthn appropriés, il n'y a pas besoin de s'inquiéter des limitations de stockage de l'authentificateur. Cela peut être particulièrement avantageux pour les authentificateurs à faible stockage, comme les clés de sécurité (par exemple, les YubiKeys).

Inconvénients :

1. Moins bonne UX car l'identifiant utilisateur est requis : Le plus grand inconvénient des clés non résidentes est que l'identifiant utilisateur (par exemple, e-mail, numéro de téléphone, nom d'utilisateur) doit être fourni par l'utilisateur, ce qui rend impossible un pré-remplissage du nom d'utilisateur via l'interface utilisateur conditionnelle (Conditional UI). Cet identifiant utilisateur doit être lié au Credential ID qui est nécessaire pour calculer la clé éphémère encapsulée.
2. Potentiel de mauvaise gestion : Les RP doivent gérer et sécuriser les associations entre les comptes utilisateurs et les clés publiques. Une mauvaise gestion ou des vulnérabilités pourraient entraîner des problèmes de sécurité.

Cas d'usage : Idéal pour les authentificateurs itinérants comme les clés de sécurité (par exemple, les YubiKeys) qui sont utilisées sur plusieurs services ou plateformes.

Imaginez que vous avez une clé de sécurité (par exemple, une YubiKey) et que vous l'enregistrez auprès de deux services en ligne : le service A et le service B. Pour le service A, vous utilisez une clé résidente. Pour le service B, une clé non résidente. Lorsque vous vous authentifiez auprès du service A, il vous suffit de toucher votre clé de sécurité (par exemple, YubiKey) et vous êtes connecté - pas besoin de spécifier un nom d'utilisateur. Pour le service B, vous devez d'abord fournir votre nom d'utilisateur dans le navigateur / l'application native. Le service envoie alors le Credential ID associé à votre clé de sécurité (par exemple, YubiKey), qui régénère alors la clé privée éphémère pour l'authentification.

En substance, bien que les clés résidentes et non résidentes améliorent la sécurité en tirant parti de l'authentification cryptographique, leurs expériences utilisateur et leurs mécanismes de stockage diffèrent, répondant à des cas d'usage variés.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

L'interface utilisateur conditionnelle (Conditional UI) est une fonctionnalité phare des passkeys / WebAuthn. Elle soulage encore plus l'utilisateur, qui non seulement n'a pas besoin de se souvenir d'un mot de passe, mais n'a pas non plus besoin de se souvenir de l'identifiant utilisateur (par exemple, e-mail, numéro de téléphone, nom d'utilisateur) avec lequel il s'est inscrit auprès d'une Partie de confiance. C'est un grand pas en avant, surtout dans les cas où les services des Parties de confiance ne sont utilisés qu'occasionnellement.

Cela fonctionne car dès que la page de connexion est ouverte, le serveur de la Partie de confiance envoie un défi en arrière-plan au client (rappelez-vous qu'il n'y a pas de Credential ID à envoyer dans cet appel). Le client prend ce défi, vérifie quels passkeys correspondent à l'ID de la Partie de confiance sur cet authentificateur et propose la sélection via le menu de remplissage automatique, où l'utilisateur peut sélectionner le passkey approprié.

De plus, cela évite à l'utilisateur un clic supplémentaire sur le bouton de connexion, car dès que le passkey est sélectionné dans le menu de remplissage automatique, le processus de connexion démarre.

Le CTAP est un protocole fondamental de la norme FIDO2, comblant le fossé de communication entre les clients (comme les navigateurs) et les authentificateurs (comme les clés de sécurité, par exemple les YubiKeys, ou les smartphones). Pour mieux comprendre le CTAP, jetons d'abord un bref coup d'œil aux différentes versions du protocole avant d'analyser l'impact sur les clés résidentes et non résidentes.

La version antérieure, souvent appelée Universal 2nd Factor (U2F), était principalement conçue pour l'authentification à deux facteurs. Dans U2F, le serveur fournit un défi, et l'authentificateur fournit une réponse, prouvant la possession de la clé privée. Cependant, U2F ne prend pas en charge les clés résidentes, ce qui signifie qu'il nécessite toujours une recherche côté serveur pour identifier quelle clé utiliser pour un utilisateur, car cela faisait partie du processus lors de la demande d'un deuxième facteur.

Successeur de U2F, CTAP2 a introduit la prise en charge des clés résidentes, permettant une authentification sans mot de passe et sans nom d'utilisateur. Avec les clés résidentes, l'authentificateur stocke le nom d'utilisateur et le Credential ID (avec l'ID de la Partie de confiance), éliminant le besoin pour le serveur de la Partie de confiance de le fournir lors de l'authentification. C'est un bond en avant significatif vers une UX plus fluide.

Cependant, CTAP2 présente des défis. Un problème notable est la gestion des clés résidentes. Par exemple, la suppression d'une clé résidente spécifique dans un appareil CTAP2.0 nécessite souvent une réinitialisation complète de l'appareil (votre clé maîtresse est donc également réinitialisée, ce qui signifie que toutes vos clés non résidentes ne fonctionneront plus), ce qui n'est pas convivial et peut être problématique dans les scénarios où plusieurs clés résidentes sont stockées sur un seul appareil. Cela fait des clés résidentes sur un appareil CTAP2.0 un engagement sérieux. Vous ne voulez vraiment pas remplir accidentellement cet espace limité que vous avez souvent, en particulier sur les clés de sécurité (par exemple, les YubiKeys).

CTAP2.1 est une version ultérieure de CTAP2, apportant des fonctionnalités et des améliorations supplémentaires au protocole. Voici quelques points clés sur CTAP 2.1 :

• Meilleure gestion des clés résidentes : CTAP 2.1 permet de gérer, mettre à jour et supprimer individuellement des clés résidentes spécifiques de votre appareil.
• Attestation d'entreprise : Cette fonctionnalité permet aux entreprises d'avoir plus de contrôle sur les clés utilisées par leurs employés. Elle offre un moyen pour les entreprises de vérifier que les clés utilisées sont bien celles émises par l'entreprise.
• Reconnaissances d'utilisateurs multiples : Certains authentificateurs peuvent reconnaître plusieurs utilisateurs. CTAP 2.1 fournit un moyen pour ces authentificateurs d'indiquer quel utilisateur a été reconnu.
• Compatibilité descendante : CTAP 2.1 est conçu pour être compatible avec CTAP2, garantissant que les appareils et les plateformes qui prennent en charge l'ancienne version peuvent toujours fonctionner avec la nouvelle.

Après avoir examiné les clés résidentes, les clés non résidentes et les différentes versions de CTAP, nous allons maintenant analyser plus en profondeur le côté de la Partie de confiance et donc le côté serveur WebAuthn.

La flexibilité (mais aussi la complexité) de WebAuthn est largement attribuée à ses paramètres de serveur, en particulier au sein de l'objet authenticatorSelection. Cet objet guide le client dans la sélection du bon authentificateur pour la tâche.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Cette option de serveur spécifie comment l'authentificateur est attaché à l'appareil client. Elle donne des indications sur la manière dont l'authentificateur communique avec le client :

Valeurs possibles

• Platform : Indique que l'authentificateur est attaché à la plateforme du client et n'est donc pas amovible.
• Cross-platform : Indique que l'authentificateur n'est pas lié à la plateforme du client et peut être utilisé sur plusieurs appareils.

Cas d'usage et exemples

• Platform : Exemples : un lecteur d'empreintes digitales intégré à un ordinateur portable ou un système de reconnaissance faciale sur un téléphone, comme Face ID, Touch ID ou Windows Hello.
• Cross-platform : Exemples : clés de sécurité USB (par exemple, YubiKeys), appareils Bluetooth ou cartes NFC.

Dans la spécification WebAuthn de niveau 1, cette option de serveur s'appelait requireResidentKey et pouvait prendre les valeurs booléennes true (l'authentificateur doit créer une clé résidente) ou false (l'authentificateur doit créer une clé non résidente). WebAuthn Niveau 2 a remplacé cette option de serveur par la nouvelle option residentKey :

Valeurs possibles

• Required : L'authentificateur doit créer une clé résidente (si ce n'est pas possible, l'opération devrait échouer).
• Preferred : L'authentificateur devrait essayer de créer une clé résidente (si ce n'est pas possible, il devrait créer une clé non résidente).
• Discouraged : L'authentificateur doit créer une clé non résidente (si ce n'est pas possible, l'opération devrait échouer).

Cas d'usage et exemples

• Required : Idéal pour les scénarios où l'on souhaite une connexion sans nom d'utilisateur ou où les utilisateurs ne devraient s'authentifier qu'à partir d'appareils précédemment enregistrés (en ajoutant une couche de sécurité supplémentaire en liant l'information d'identification de l'utilisateur à un appareil spécifique).
• Preferred : Convient aux scénarios où le service web souhaite offrir la meilleure expérience de connexion possible (via les clés résidentes), mais veut tout de même prendre en charge les clés non résidentes si les clés résidentes ne sont pas possibles.
• Discouraged : Un service souhaite offrir l'authentification par passkey et veut également s'assurer que les utilisateurs peuvent utiliser n'importe quel authentificateur, même ceux sans capacité de stockage, sans lier l'information d'identification à un appareil spécifique.

La vérification de l'utilisateur fait référence au processus qui garantit que la personne interagissant avec l'authentificateur est le propriétaire légitime, généralement en exigeant un geste d'authentification spécifique comme la saisie d'un code PIN, la fourniture d'une empreinte digitale ou l'utilisation de la reconnaissance faciale.

Parfois, la présence de l'utilisateur (UP) est également mentionnée ou utilisée de manière similaire à la vérification de l'utilisateur, mais il y a quelques différences. La présence de l'utilisateur confirme seulement que quelqu'un - n'importe qui - est physiquement présent et interagit avec l'appareil. Elle ne vérifie pas l'identité de cette personne. Un simple contact sur une clé de sécurité, sans autre contrôle d'identité, peut suffire pour la présence de l'utilisateur. Pour les passkeys / WebAuthn, l'utilisateur doit toujours être présent.

Valeurs possibles

• Required : L'opération doit comporter une vérification de l'utilisateur.
• Preferred : L'opération devrait comporter une vérification de l'utilisateur si possible, mais peut se poursuivre sans.
• Discouraged : L'opération ne devrait pas comporter de vérification de l'utilisateur.

Cas d'usage et exemples

• Required : Idéal pour les applications à haute sécurité comme les services bancaires ou les soins de santé, où la vérification de l'identité de l'utilisateur (par exemple, par une empreinte digitale ou un code PIN) est cruciale.
• Preferred : Utile pour les applications générales où une sécurité supplémentaire est un bonus mais pas strictement nécessaire.
• Discouraged : Convient pour les opérations à faible risque ou les scénarios où la vérification de l'utilisateur pourrait être un inconvénient.

Modèle

• authenticatorAttachment : platform
• residentKey : required
• userVerification : required

Exemple : Une application d'entreprise souhaite que les employés se connectent sans mot de passe sur leurs ordinateurs portables fournis par l'entreprise en utilisant les lecteurs d'empreintes digitales intégrés. L'information d'identification est stockée sur l'appareil, et l'utilisateur doit se vérifier avec une empreinte digitale à chaque fois.

Modèle

• authenticatorAttachment : cross-platform
• residentKey : required
• userVerification : required

Exemple : Un utilisateur enregistre une clé de sécurité (par exemple, une YubiKey) pour sa banque en ligne. Il peut utiliser cette clé pour s'authentifier sur n'importe quel appareil en présentant la clé de sécurité (par exemple, YubiKey), sans avoir besoin de saisir un nom d'utilisateur.

De nombreuses clés de sécurité matérielles (par exemple, les YubiKeys) ont des contraintes de stockage inhérentes. Cette limitation est due à la mémoire physique disponible sur l'appareil et aux considérations de conception du fabricant.

Exemple : Une YubiKey peut avoir la capacité de stocker seulement 20 clés résidentes. Une fois cette limite atteinte, aucune clé résidente supplémentaire ne peut être ajoutée sans en supprimer d'existantes.

Solution :

• Utilisation sélective des clés résidentes : Au lieu d'utiliser des clés résidentes pour chaque utilisateur, envisagez-les pour des rôles ou des scénarios spécifiques. Par exemple, donnez la priorité aux clés résidentes pour les rôles d'administrateur ou les utilisateurs à privilèges élevés qui nécessitent une sécurité renforcée.
• Éducation des utilisateurs : Informez les utilisateurs des limitations de leurs clés de sécurité (par exemple, les YubiKeys). Encouragez-les à passer à des appareils qui peuvent utiliser un nombre illimité de clés résidentes, comme les ordinateurs portables ou les smartphones.

Différents authentificateurs peuvent gérer les demandes de clés résidentes différemment. Certains peuvent par défaut créer une clé résidente même si ce n'est pas explicitement demandé, tandis que d'autres peuvent nécessiter une instruction explicite.

Le comportement incohérent pour différentes options de serveur WebAuthn sur différentes plateformes est un problème majeur. Par exemple, iOS créera toujours une clé résidente quelles que soient les options de serveur WebAuthn transmises, tandis qu'Android nécessite une adhésion explicite (par exemple, avec residentKey: preferred ou residentKey: required).

Outre le comportement, ce qui est encore pire, c'est que sur la base des données stockées côté serveur, vous ne pouvez pas dire avec une certitude de 100 % si une information d'identification stockée est une clé résidente ou une clé non résidente. Au lieu de cela, vous pouvez suivre quelques vérifications et affiner votre estimation (voir ci-dessous), mais vous devez toujours espérer que le comportement de l'information d'identification est conforme à ce que vous croyez.

La raison en est qu'il existe une suggestion WebAuthn pour stocker des informations sur le type d'information d'identification (clé résidente ou clé non résidente) dans l'extension des propriétés de l'information d'identification (clientExtensionResults.credProps.rk qui est soit true soit false). Cependant, la fourniture de cette information à la RP n'est pas garantie car toutes les extensions WebAuthn sont facultatives, par exemple iOS ne l'envoie pas (vous ne savez donc pas si c'est une clé résidente ou non résidente).

Au cours de nos recherches, nous avons essayé de tester le comportement sur différentes plateformes et authentificateurs (Windows 10, Windows 11, Android 7, Android 13, iOS 17, macOS Ventura, YubiKey) avec deux pages de démonstration WebAuthn qui fournissent plus de détails sur les informations d'identification créées : https://webauthn.io et https://webauthntest.identitystandards.io/. Cette dernière offre la possibilité de travailler avec l'ancienne propriété requireResidentKey (WebAuthn Niveau 1) et même de la combiner avec la propriété residentKey (WebAuthn Niveau 2). Cependant, les résultats n'étaient pas fiables (par exemple, il indiquait une clé non résidente pour iOS alors que l'interface utilisateur conditionnelle fonctionnait clairement).

Le schéma de vérification le plus fiable que nous avons trouvé est le suivant :

1. Vérifiez les paramètres de votre serveur WebAuthn pour l'attribut "residentKey"
   1. Si "residentKey: required" et qu'une information d'identification est créée avec succès -> c'est une clé résidente
   2. Si "residentKey: preferred" ou "residentKey: discouraged", passez à la vérification suivante
2. L'extension credProps.rk est-elle prise en charge et stockée dans l'information d'identification sur le serveur ?
   1. Si credProps.rk = true, l'information d'identification est une clé résidente
   2. Si credProps.rk = false, l'information d'identification est une clé non résidente
   3. Si credProps est vide, alors le type d'information d'identification est inconnu

Comme vous pouvez le voir, cela aide à affiner, mais l'option inconnue demeure et vous ne pouvez pas déterminer le type de clé avec une certitude de 100 %.

Ceci est également conforme aux conclusions de William Brown de SUSE dans son excellent article soulignant comment les clés de sécurité (par exemple, les YubiKeys) pourraient être inutiles si les clés résidentes sont requises par les Parties de confiance (nous avons étendu son tableau) :

Dans le tableau, vous voyez pour différentes options de clé résidente du serveur WebAuthn si une clé résidente a été créée (true), si une clé non résidente a été créée (false) ou si autre chose s'est produit.

Solution :

• Tests approfondis : Avant le déploiement, testez votre implémentation WebAuthn sur une gamme d'authentificateurs populaires pour comprendre leur comportement.
• Paramètres de serveur explicites : Lors de la configuration de votre serveur WebAuthn, soyez explicite dans vos exigences. Si vous ne voulez que des passkeys, alors réglez l'option residentKey sur required (notez que cela peut entraîner d'autres défis avec les authentificateurs à capacité de clé résidente limitée, voir ci-dessus).

Si un utilisateur atteint la limite de stockage sur sa clé de sécurité (par exemple, YubiKey), il peut rencontrer des erreurs ou être incapable d'enregistrer de nouvelles informations d'identification. Cela peut entraîner confusion et frustration.

Solution :

• Gestion des erreurs en douceur : Mettez en œuvre des messages d'erreur clairs qui informent l'utilisateur lorsque sa clé de sécurité (par exemple, YubiKey) est pleine et fournissez des conseils sur la manière de résoudre le problème.
• Flux de travail guidés : Proposez des guides étape par étape ou des tutoriels sur la manière dont les utilisateurs peuvent gérer leurs clés résidentes, en veillant à ce qu'ils puissent résoudre les problèmes de manière autonome.

9. Bonnes pratiques pour les développeurs et les chefs de produit

Comme vous l'avez vu ci-dessus, les paramètres de serveur WebAuthn que vous choisissez peuvent avoir un impact significatif sur l'expérience utilisateur et la sécurité de votre processus d'authentification. Il est essentiel de comprendre les nuances de ces paramètres pour prendre des décisions éclairées.

Clés résidentes vs non résidentes : Si une majorité de vos utilisateurs accèdent principalement à votre service depuis des appareils personnels comme des smartphones ou des ordinateurs portables, les clés résidentes sont un choix approprié. Les clés résidentes sont stockées sur l'appareil lui-même et offrent une expérience d'authentification fluide pour les utilisateurs qui utilisent fréquemment le même appareil. Cependant, pour les utilisateurs qui utilisent des clés de sécurité (par exemple, des YubiKeys), les clés non résidentes peuvent être plus appropriées.

Paramètres de vérification de l'utilisateur (UV) : Selon le niveau de sécurité que vous souhaitez atteindre, vous pouvez décider de la rigueur du processus de vérification de l'utilisateur. Si vous visez une sécurité élevée, exiger un code PIN, une empreinte digitale ou une reconnaissance faciale (userVerification: preferred ou userVerification: required) est conseillé.

Attestation et fiabilité : L'attestation vous permet de vérifier l'origine et l'intégrité de l'authentificateur. Décidez si vous voulez faire confiance à tous les authentificateurs ou seulement à ceux de fabricants spécifiques. Cela peut être crucial si vous traitez des données sensibles et que vous voulez vous assurer que seuls des authentificateurs de haute qualité et fiables sont utilisés.

Mécanismes de secours : Ayez toujours un mécanisme de secours en place. Si un utilisateur perd son authentificateur ou s'il fonctionne mal, il doit avoir un autre moyen d'accéder à son compte. Cela pourrait être par des codes de secours, une vérification par SMS, des liens magiques par e-mail ou d'autres méthodes d'authentification multifacteur.

Formation continue : Le paysage des passkeys et de WebAuthn est en constante évolution. Restez à jour avec les derniers développements, vulnérabilités et correctifs. Encouragez votre équipe de développement à participer à des ateliers, des webinaires et des conférences sur les passkeys et WebAuthn.

Intégration et éducation des utilisateurs : Lorsque vous introduisez l'authentification par passkey, assurez-vous que vos utilisateurs comprennent ses avantages et son fonctionnement. Offrez des instructions claires pendant le processus d'inscription et fournissez des ressources (comme des FAQ ou des tutoriels vidéo) pour aider les utilisateurs à configurer et à utiliser les passkeys.

En adhérant à ces bonnes pratiques, les développeurs et les chefs de produit peuvent s'assurer qu'ils mettent en œuvre l'authentification par passkey efficacement, en équilibrant à la fois la sécurité et l'expérience utilisateur.

Si vous souhaitez mettre en œuvre des passkeys pour une adoption grand public sur votre site web ou votre application et que vous n'avez pas besoin de prendre en charge les clés de sécurité (par exemple, les YubiKeys), car la plupart de vos utilisateurs utiliseront simplement leur smartphone ou leur ordinateur portable, nous vous recommandons les paramètres suivants.

• authenticator : platform
• residentKey : required
• userVerification : required

Avantages :

• Comme toutes les clés créées sont des clés résidentes, la configuration permet l'interface utilisateur conditionnelle (Conditional UI), rendant votre connexion encore plus fluide pour vos utilisateurs car ils n'ont pas à se souvenir d'un nom d'utilisateur.
• Tous les appareils modernes d'Apple, Google et Microsoft sont pris en charge et utilisent des passkeys.

Les paramètres du serveur WebAuthn, bien que complexes, offrent un cadre robuste et flexible pour l'authentification. Maîtriser ces paramètres est crucial, car il ne s'agit pas seulement de mettre en œuvre une nouvelle norme ; il s'agit d'améliorer fondamentalement la sécurité et l'efficacité de l'authentification des utilisateurs.

En substance, comprendre les paramètres du serveur WebAuthn est un investissement dans la création d'applications plus sécurisées, efficaces et tournées vers l'avenir. À mesure que le paysage numérique évolue, être bien informé sur de telles technologies sera indispensable. Pour rester à jour, rejoignez notre communauté sur les passkeys ou abonnez-vous à notre newsletter ci-dessous.