--- url: 'https://www.corbado.com/fr/blog/cle-residente-webauthn-credentials-decouvrables-passkeys' title: 'Clé résidente WebAuthn : les informations d''identification détectables en tant que passkeys' description: 'Des configurations incorrectes des serveurs WebAuthn peuvent entraîner des problèmes d''UX et perturber les passkeys existants. Ce guide aide les développeurs à configurer les serveurs WebAuthn.' lang: 'fr' author: 'Vincent Delitz' date: '2025-08-20T15:38:49.477Z' lastModified: '2026-09-16T06:04:42.094Z' keywords: 'clé résidente, identifiant détectable, clé non résidente, identifiant non détectable' category: 'WebAuthn Know-How' --- # Clé résidente WebAuthn : les informations d'identification détectables en tant que passkeys ## 1. Introduction Les [passkeys](https://www.corbado.com/category/passkeys-strategy) et le protocole sous-jacent WebAuthn révolutionnent le paysage de l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys). Cependant, configurer correctement un serveur WebAuthn peut s'avérer délicat. Les erreurs de configuration peuvent non seulement introduire des [vulnérabilités](https://www.corbado.com/fr/blog/fuite-donnees-medibank), 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. ## 2. L'écosystème WebAuthn 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](https://www.corbado.com/glossary/windows-hello) ou Touch ID / [Face ID](https://www.corbado.com/faq/is-face-id-passkey) d'[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android)) 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) 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é. Ci-dessous, nous décrivons le flux de données de haut niveau lors d'un processus d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) (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](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee), 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](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee), l'authentificateur signe le défi et renvoie cette [assertion](https://www.corbado.com/glossary/assertion) signée au client. 5. **Du client à la RP :** Le client transmet cette nouvelle clé publique / l'[assertion](https://www.corbado.com/glossary/assertion) signée à la RP. 6. **Vérification par la RP :** La RP stocke la clé publique / vérifie l'[assertion](https://www.corbado.com/glossary/assertion) signée à l'aide de la clé publique stockée. Si elle est valide, l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) est réussie. ## 3. Plongée au cœur des passkeys Le flux de processus de haut niveau décrit ci-dessus concerne les processus d'inscription et de [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) 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](https://www.corbado.com/blog/webauthn-user-id-userhandle) 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys). Elle englobe à la fois les données d'[attestation](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/fr/glossary/relying-party) peut alors vérifier que la signature provient d'un authentificateur spécifique autorisé (par exemple, une [YubiKey](https://www.corbado.com/glossary/yubikey)). Tous les authentificateurs de passkeys ne répondent pas avec une telle [attestation](https://www.corbado.com/glossary/attestation) ; certains ne renvoient tout simplement pas de données utiles (voir [ici](https://github.com/passkeydeveloper/passkey-authenticator-aaguids/blob/main/aaguid.json) la liste des authentificateurs de passkeys). D'autres [AAGUID](https://www.corbado.com/glossary/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](https://fidoalliance.org/metadata/). - **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. » ## 4. Que sont les clés résidentes et les clés non résidentes ? 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. ### 4.1 Clés résidentes (RK) **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](https://www.corbado.com/glossary/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)](#conditional-ui-passkey-autofill) 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. > Les clés résidentes sont aussi souvent appelées « informations d'identification > détectables » (discoverable credentials), car le client peut découvrir une liste de clés > possibles depuis l'authentificateur qui correspondent à l'ID de la > [Partie de confiance](https://www.corbado.com/fr/glossary/relying-party) (rpID) en question et afficher une > liste des identifiants utilisateur possibles / stockés (par exemple, e-mails, numéros de > téléphone, noms d'utilisateur) de l'appareil. 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](https://www.corbado.com/glossary/yubikey). Les clés non résidentes ne figurent pas dans la liste, car elles ne sont pas stockées sur l'authentificateur : ![Yubikey Manager Resident Keys](https://www.corbado.com/website-assets/6517dbcd905582d132f08cc2_yubikey_manager_fido_discoverable_credentials_3f3f110283.png) **Flux de connexion :** ![WebAuthn Resident key flow](https://www.corbado.com/website-assets/65170ca733125d4a5908b0c2_webauthn_resident_key_flow_bd5ddbfb26.png)_Source : [William Brown](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/)_ Lors du processus de connexion, la [Partie de confiance](https://www.corbado.com/fr/glossary/relying-party) 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](#conditional-ui-passkey-autofill) 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](https://www.corbado.com/fr/blog/comment-utiliser-gestionnaire-mots-de-passe-google)) ou un [gestionnaire de mots de passe](https://www.corbado.com/fr/blog/cles-dacces-brave-browser) moderne (par exemple, [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) ou [Dashlane](https://www.corbado.com/blog/dashlane-passkeys)) 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. ### 4.2 Clés non résidentes (NRK) **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](https://www.corbado.com/blog/webauthn-user-id-userhandle) (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](https://www.corbado.com/blog/webauthn-user-id-userhandle), 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. > Les clés non résidentes sont aussi souvent appelées « informations d'identification non > détectables » (non-discoverable credentials), car l'authentificateur ne peut pas > découvrir / rechercher des clés pour un ID de Partie de confiance (rpID) spécifique. > Sans le Credential ID, l'authentificateur ne sait même pas qu'il pourrait y avoir une > clé. **Flux de connexion :** ![WebAuthn Non-resident key flow](https://www.corbado.com/website-assets/65170dade63f226249823f7d_webauthn_non_resident_key_flow_09fc4da6c1.png)_Source : [William Brown](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/)_ 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](https://github.com/w3c/webauthn/issues/1612#issuecomment-840961012). 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](https://www.corbado.com/fr/blog/fuite-donnees-medibank) 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. ### 4.3 Exemple 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](https://www.corbado.com/fr/blog/applications-natives-passkeys). 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. ## 5. Conditional UI (« remplissage automatique des passkeys ») 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](https://www.corbado.com/fr/blog/comment-activer-passkeys-android), 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](https://www.corbado.com/fr/blog/webauthn-conditional-ui-remplissage-automatique-passkeys), 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](https://www.corbado.com/fr/blog/webauthn-conditional-ui-remplissage-automatique-passkeys), le processus de connexion démarre. > L'interface utilisateur conditionnelle (remplissage automatique des passkeys) ne > fonctionne que pour les clés résidentes. ## 6. Protocole Client to Authenticator (CTAP) Le [CTAP](https://www.corbado.com/fr/glossary/ctap) est un protocole fondamental de la norme [FIDO2](https://www.corbado.com/glossary/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](https://www.corbado.com/fr/glossary/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. ### 6.1 CTAP1 (U2F) 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. ### 6.2 CTAP2 Successeur de U2F, CTAP2 a introduit la prise en charge des clés résidentes, permettant une [authentification sans mot de passe](https://www.corbado.com/fr/blog/webauthn-conditional-ui-remplissage-automatique-passkeys) 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). ### 6.3 CTAP2.1 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](https://www.corbado.com/fr/glossary/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](https://www.corbado.com/fr/blog/violations-donnees-japon) d'avoir plus de contrôle sur les clés utilisées par leurs employés. Elle offre un moyen pour les [entreprises](https://www.corbado.com/fr/blog/violations-donnees-japon) 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. ## 7. Options du serveur WebAuthn 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](https://www.corbado.com/glossary/authenticatorselection). Cet objet guide le client dans la sélection du bon authentificateur pour la tâche. ```json { "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 } } ``` ### 7.1 Option de serveur WebAuthn : authenticatorAttachment 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](https://www.corbado.com/faq/is-face-id-passkey), Touch ID ou [Windows Hello](https://www.corbado.com/glossary/windows-hello). - **Cross-platform :** Exemples : clés de sécurité USB (par exemple, YubiKeys), appareils Bluetooth ou cartes NFC. ### 7.2 Option de serveur WebAuthn : Resident Key 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](https://developers.yubico.com/WebAuthn/Concepts/WebAuthn_Level_2_Features_and_Enhancements.html) 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. ### 7.3 Option de serveur WebAuthn : User Verification 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](https://www.corbado.com/passkeys-for-banking) ou les [soins de santé](https://www.corbado.com/passkeys-for-healthcare), 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. ### 7.4 Modèles courants d'options de serveur WebAuthn #### 7.4.1 Connexion sans mot de passe avec des passkeys via Face ID / Touch ID **Modèle** - authenticatorAttachment : platform - residentKey : required - [userVerification](https://www.corbado.com/glossary/user-verification) : required **Exemple :** Une application d'entreprise souhaite que les employés se connectent [sans mot de passe](https://www.corbado.com/fr/blog/comment-passer-totalement-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. #### 7.4.2 Connexion sans mot de passe avec des clés de sécurité **Modèle** - authenticatorAttachment : cross-platform - residentKey : required - [userVerification](https://www.corbado.com/glossary/user-verification) : required **Exemple :** Un utilisateur enregistre une clé de sécurité (par exemple, une YubiKey) pour sa [banque en ligne](https://www.corbado.com/passkeys-for-banking). 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. ## 8. Défis potentiels et solutions ### 8.1 Défi 1 : Limitations de stockage des clés de sécurité De nombreuses [clés de sécurité matérielles](https://www.corbado.com/fr/blog/meilleures-cles-securite-materielles-fido2-2026) (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. ### 8.2 Défi 2 : Comportement incohérent entre les authentificateurs 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) créera toujours une clé résidente quelles que soient les options de serveur WebAuthn transmises, tandis qu'[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://w3c.github.io/webauthn/#sctn-authenticator-credential-properties-extension) (`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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/passkeys-windows-11), [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 7, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 13, [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration), 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](https://webauthn.io) et [https://webauthntest.identitystandards.io/](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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) alors que l'interface utilisateur conditionnelle fonctionnait clairement). Le schéma de vérification le plus fiable que [nous avons trouvé](https://github.com/duo-labs/webauthn.io/issues/68#issuecomment-1321086293) 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](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/) 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) : ![WebAuthn Resident key behavior for different resident key options and platforms / authenticators](https://www.corbado.com/website-assets/6517169ef6b267c5861a1331_resident_key_table_operating_system_cc647fbf5b.png) 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](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) 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). ### 8.3 Défi 3 : Préoccupations relatives à l'expérience utilisateur 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](https://www.corbado.com/fr/blog/fuite-donnees-medibank) 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](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) 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. ## 10. Recommandation 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](https://www.corbado.com/glossary/authenticator) : platform - residentKey : required - [userVerification](https://www.corbado.com/glossary/user-verification) : 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](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android), Google et Microsoft sont pris en charge et utilisent des passkeys. ## 11. Conclusion 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](https://bit.ly/passkeys-community) ou abonnez-vous à notre newsletter ci-dessous.