---
url: 'https://www.corbado.com/fr/blog/aide-memoire-cles-dacces'
title: 'Aide-mémoire sur les clés d''accès pour les développeurs'
description: 'Le guide du développeur sur WebAuthn et l''implémentation des clés d''accès. Téléchargez l''aide-mémoire en PDF ou utilisez ce site web pour tout avoir au même endroit.'
lang: 'fr'
author: 'Lukas R.'
date: '2026-07-03T07:12:41.238Z'
lastModified: '2026-07-03T07:12:54.815Z'
keywords: 'aide-mémoire, clés d''accès, développeurs, WebAuthn, implémentation, PDF'
category: 'Passkeys Implementation'
---
# Aide-mémoire sur les clés d'accès pour les développeurs
## Téléchargez-le gratuitement ici
Téléchargez l'**Aide-mémoire sur les clés d'accès gratuitement** pour obtenir toutes les informations.
- ✅ Plus de 4 000 téléchargements
- ✅ Demandé par les équipes de développement d'Ally, Kmart, Octopus [Energy](https://www.corbado.com/passkeys-for-energy) et Stanford CS
- ✅ Pas de blabla marketing - uniquement des informations techniques
## Key Facts
- L'authentification par clés d'accès utilise deux **cérémonies** : l'enregistrement (attestation) et la connexion (assertion), chacune nécessitant un défi aléatoire généré par le serveur et signé par l'authentificateur.
- **PublicKeyCredentialCreationOptions** régit l'enregistrement de la clé d'accès, tandis que **PublicKeyCredentialRequestOptions** régit la connexion. Les deux objets sont générés côté serveur et contiennent le défi que l'authentificateur doit signer.
- L'**interface conditionnelle** (Conditional UI) affiche les clés d'accès disponibles sous forme de suggestions de saisie automatique, mais nécessite des identifiants découvrables (clés résidentes) et n'est pas prise en charge sur toutes les combinaisons de systèmes d'exploitation et de navigateurs.
- L'**identifiant de la partie de confiance (rpID)** lie une clé d'accès à un domaine : l'authentification ne réussit que si l'URL correspond ou est un sous-domaine (qui n'est pas un suffixe public) du rpID.
- Les clés d'accès utilisent les **algorithmes COSE** pour la génération de clés, l'algorithme spécifique étant enregistré dans l'attribut `parsedCredentialPublicKey` de l'objet d'attestation.
## 1. Cérémonies WebAuthn
L'authentification par clés d'accès repose sur deux processus, également appelés cérémonies : l'**enregistrement** (ou la **phase d'attestation**) et la **connexion** (ou la **phase d'assertion**).
Chaque phase nécessite un défi aléatoire généré par le serveur, qui est signé par l'authentificateur et renvoyé au serveur WebAuthn pour vérifier l'utilisateur.
### 1.1 Enregistrement (Attestation)
_La cérémonie d'enregistrement utilise deux objets centraux : PublicKeyCredentialCreationOptions et l'attestation._
[Watch on YouTube](https://www.youtube.com/watch?v=0hRYXHESA24)
### 1.2 Connexion (Assertion)
_La cérémonie de connexion utilise deux objets centraux : PublicKeyCredentialRequestOptions et l'assertion._
## 2. Objets importants
Pour l'enregistrement et la connexion avec des clés d'accès, il existe quatre objets principaux :
- PublicKeyCredentialCreationOptions
- PublicKeyCredentialRequestOptions
- attestation
- assertion
Cette section explique également l'objet `authenticatorSelection`, qui est utilisé dans les `PublicKeyCredentialCreationOptions`.
### 2.1 Public Key Credential Creation Options
`PublicKeyCredentialCreationOptions` est l'objet central de la phase d'attestation (Enregistrement). Il est créé et renvoyé par le [serveur WebAuthn](#webauthn-server).
```json
{
"PublicKeyCredentialCreationOptions": {
"rp": {
"id": "passkeys.eu",
"name": "Corbado Passkeys Demo"
},
"user": {
"displayName": "john.doe",
"id": "dXNyLZ….DU10Tc",
"name": "john@doe.com"
},
"challenge": "888fix4Bus...pHHr3Y",
"pubKeyCredParams": [
{
"alg": -7,
"type": "public-key"
},
{
"alg": -257,
"type": "public-key"
}
],
"excludeCredentials": [],
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
},
"attestation": "none",
"extensions": {}
}
}
```
L'objet contient ces attributs :
- **rp :** Identifie la partie de confiance (Relying Party = le serveur cherchant à authentifier l'utilisateur), voir la section [4.2 Identifiant de la partie de confiance (rpID).](#relying-party-id)
- **user :** Contient des données sur le compte utilisateur demandant l'attestation. L'ID est une séquence d'octets choisie par la partie de confiance, qui ne doit pas contenir d'informations personnelles. Le nom d'utilisateur ou l'adresse e-mail est plutôt enregistré dans l'attribut `name` ou `displayName`. Pour en savoir plus, consultez la section [4.1 Schéma de base de données.](#database-schema)
- **challenge :** Une `BufferSource` encodée en base64URL générée de manière aléatoire qui doit être signée par l'authentificateur.
- **pubKeyCredParams :** Attributs spécifiés de l'identifiant à créer, généralement le(s) algorithme(s) pris en charge.
- **timeout :** Temps facultatif en millisecondes pendant lequel le client doit attendre la fin de l'appel.
- **excludeCredentials :** Liste facultative d'identifiants pour limiter la création de plusieurs clés d'accès sur un seul appareil.
- **authenticatorSelection :** Sélection facultative de l'authentificateur utilisé pour la méthode, par exemple si une `residentKey` est requise. Voir [2.5 authenticatorSelection](#authenticatorSelection).
- **attestation :** Peut être utilisé pour demander que l'objet d'attestation soit transmis à la partie de confiance sous une forme spécifique. Les valeurs possibles sont `none` (par défaut), `indirect`, `direct` et `enterprise`.
- **extensions :** Demande(s) facultative(s) pour un traitement supplémentaire, tel que des valeurs de retour spécifiques. Par ex.
- _credProbs_ demande des informations pour savoir si l'identifiant créé est découvrable.
- _prf_ permet à la partie de confiance d'utiliser les sorties d'une fonction pseudo-aléatoire (PRF) associée à un identifiant.
### 2.2 Public Key Credential Request Options
`PublicKeyCredentialRequestOptions` est l'objet central de la phase d'assertion (Connexion). Il est créé et renvoyé par le [serveur WebAuthn](#webauthn-server).
```json
{
"publicKeyCredentialRequestOptions": {
"challenge": "pT7HMA-…dFPHk",
"timeout": 500,
"rpId": "passkeys.eu",
"userVerification": "preferred",
"allowCredentials": [],
"extensions": []
}
}
```
L'objet contient ces attributs :
- **challenge, timeout, extensions :** voir [ci-dessus](#creationoptions).
- **rpId :** L'identifiant de la partie de confiance pour la demande d'assertion, voir la section [4.2 Identifiant de la partie de confiance (rpID).](#relying-party-id)
- **allowCredentials :** Liste facultative d'identifiants autorisés pour l'authentification, indiquant la préférence des appelants par ordre décroissant. Cette liste serait remplie avec des `PublicKeyCredentialDescriptors`.
- **userVerification :** Valeur facultative pour spécifier les exigences de vérification de l'utilisateur pendant l'opération. Les valeurs possibles sont `preferred` (par défaut), `required` ou `discouraged`.
### 2.3 Attestation
Pendant la cérémonie d'**Attestation** / Enregistrement, l'authentificateur renvoie cette **Réponse d'enregistrement**. Vous pouvez l'essayer vous-même dans le [débogueur de clés d'accès](https://www.passkeys-debugger.io/).
```json
{
"authenticatorAttachment": "platform",
"id": "JKZbixUfKN_aZtimefYT-OjH5dw",
"rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
"response": {
"attestationObject": {
"fmt": "none",
"attStmt": {},
"authData": {
"rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
"flags": {
"userPresent": true,
"userVerified": true,
"backupEligible": true,
"backupStatus": true,
"attestedData": true,
"extensionData": false
},
"counter": 0,
"aaguid": {
"raw": "fbfc3007-154e-4ecc-8c0b-6e020557d7bd",
"name": "iCloud Keychain"
},
"credentialID": "JKZbixUfKN_aZtimefYT-OjH5dw",
"credentialPublicKey": "pQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
"parsedCredentialPublicKey": {
"keyType": "EC2 (2)",
"algorithm": "ES256 (-7)",
"curve": 1,
"x": "9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx0",
"y": "3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA"
}
}
},
"clientDataJSON": {
"type": "webauthn.create",
"challenge": "k2p6f-upzP_hc6NZvmMAxiI0VSTeQIeXXVRGW62LTj0",
"origin": "https://www.passkeys-debugger.io",
"crossOrigin": false
},
"transports": ["hybrid", "internal"],
"authenticatorData": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkNdAAAAAPv8MAcVTk7MjAtuAgVX170AFCSmW4sVHyjf2mbYpnn2E_jox-XcpQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA",
"publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx3cPts8hZAnzP5YWffN1hnMnD1zuaE92Z-VCoP29Xt58A",
"publicKeyAlgorithm": -7
},
"type": "public-key",
"clientExtensionResults": {}
}
```
L'**attestation** contient des composants importants tels que [attestationObject](#attestationObject), [algorithm](#algorithm) et les drapeaux de [transport](#transport).
#### 2.3.1 attestationObject
Extrait de la [spécification WebAuthn du W3C](https://www.w3.org/TR/webauthn-2/#attestation-object)
L'**attestationObject** est un objet encodé en CBOR, contenant des informations sur les identifiants nouvellement créés, la clé publique et d'autres données pertinentes :
- **fmt** est généralement évalué à "none" pour les clés d'accès.
- **attStmt** est vide pour les clés d'accès et rempli pour les autres authentificateurs, par exemple une clé de sécurité matérielle.
- **authData** est un tampon de valeurs contenant les données suivantes :
Pour en savoir plus sur les [extensions](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/WebAuthn_extensions).
#### algorithm
Les clés d'accès sont générées avec des **algorithmes COSE**, en indiquant l'algorithme utilisé dans l'**attribut algorithme** de `parsedCredentialPublicKey` dans l'[objet d'attestation](#attestation).
Voici un aperçu des algorithmes COSE les plus pertinents :
#### 2.3.2 transport
La propriété **transports** indique les mécanismes par lesquels un authentificateur peut communiquer avec un client. Voici quelques combinaisons de valeurs courantes :
- **"transports": \["internal","hybrid"]** : Les clés d'accès peuvent être utilisées depuis l'authentificateur de plateforme (par ex. Face ID, Touch ID, Windows Hello) ou via une authentification inter-appareils (à l'aide d'un code QR et du Bluetooth).
- **"transports": \["internal"]** : Les clés d'accès ne peuvent être utilisées que depuis l'authentificateur de plateforme (par ex. Face ID, Touch ID, Windows Hello).
- **Aucune propriété "transports" définie :** Comportement par défaut qui ne donne aucune indication.
### 2.4 Assertion
Pendant la cérémonie d'**Assertion** / Connexion, l'authentificateur renvoie cette **Réponse de connexion**. Vous pouvez l'essayer vous-même dans le [débogueur de clés d'accès](https://www.passkeys-debugger.io/).
```json
{
"id": "JKZbixUfKN_aZtimefYT-OjH5dw",
"rawId": "JKZbixUfKN_aZtimefYT-OjH5dw",
"type": "public-key",
"authenticatorAttachment": "platform",
"response": {
"authenticatorData": {
"rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM",
"flags": {
"userPresent": true,
"userVerified": true,
"backupEligible": true,
"backupStatus": true,
"attestedData": false,
"extensionData": false
},
"counter": 0
},
"clientDataJSON": {
"type": "webauthn.get",
"challenge": "GCVkITWbe2l2dttsn_DgJYvH9QPHPDo0ygWgcgI6B7U",
"origin": "https://www.passkeys-debugger.io",
"crossOrigin": false,
"other_keys_can_be_added_here": "do not compare clientDataJSON against a template. See https://goo.gl/yabPex"
},
"signature": "MEQCIA-orC8N2KKWOxyY17BWP8lB-Be5to9btXRnJZf2SLhXAiBGxJe5Eu5LwOTbsyzAYmIXHOhlC3pN7s7Q1fRLvEW57g",
"userHandle": "_FKz1uwqmR_3yGq6hJntzoIFwFC_d1u_53YRELh0KlE"
}
}
```
L'**assertion** contient des composants importants tels que les drapeaux, la signature et le `userHandle`.
#### 2.4.1 flags
Voici un aperçu des **drapeaux (flags)** les plus pertinents et de leurs combinaisons :
#### 2.4.2 signature
La **signature** est utilisée pour vérifier que l'utilisateur qui tente de se connecter possède réellement la clé privée. La signature est créée en concaténant `authenticatorData` et `clientDataHash` (c'est-à-dire la version SHA-256 de `ClientDataJSON`) et en signant le résultat avec la clé privée (dans l'authentificateur). Pour vérifier avec la clé publique, nous concaténons également `authenticatorData` et `clientDataHash`. Si le résultat de la vérification est vrai, l'authentification est réussie.
#### 2.4.3 userHandle
Le **userHandle** est l'ID utilisateur (`user_id`) réel. Pour en savoir plus sur l'ID utilisateur, consultez la section [**4.1 Schéma de base de données.**](#database-schema)
### 2.5 authenticatorSelection
L'objet **authenticatorSelection** permet au serveur de dicter les paramètres pour l'authentificateur et la création d'identifiants avec les valeurs suivantes :
#### 2.5.1 authenticatorAttachment
- **Platform :** L'authentificateur est rattaché à la plateforme du client et n'est donc pas amovible.
- **Cross-platform :** L'authentificateur n'est pas lié à la plateforme du client et peut être utilisé sur plusieurs appareils.
#### 2.5.2 residentKey
- **Required :** L'authentificateur doit créer une clé résidente (si ce n'est pas possible, l'opération doit échouer).
- **Preferred :** L'authentificateur doit essayer de créer une clé résidente (si ce n'est pas possible, il doit 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 doit échouer).
> **Clés résidentes (également appelées identifiants découvrables) :** Les clés résidentes sont stockées sur l'authentificateur et récupérées lors de l'authentification. De cette façon, le client peut découvrir une liste de clés possibles, c'est pourquoi l'interface conditionnelle (Conditional UI) nécessite des clés résidentes.
> **Clés non résidentes (également appelées identifiants non découvrables) :** Dans le cas des clés non résidentes, l'ID d'identifiant est stocké sur le serveur et fourni lors de l'authentification. L'ID d'identifiant est un [identifiant opaque](https://www.w3.org/TR/webauthn-3/#sctn-credential-id) dont la structure interne est spécifique à l'implémentation. Les authentificateurs peuvent stocker des clés privées directement, utiliser l'encapsulation de clé chiffrée ou dériver des clés à partir de secrets internes. Le mécanisme exact varie selon l'implémentation de l'authentificateur.
#### 2.5.3 userVerification
- **Required :** L'opération doit vérifier l'utilisateur.
- **Preferred :** L'opération doit vérifier l'utilisateur, mais peut se poursuivre sans le faire (option standard).
- **Discouraged :** L'opération ne doit pas vérifier l'utilisateur.
> **Avertissement :** Si défini sur "**Preferred**", l'utilisateur ou son appareil peut ignorer la vérification de l'utilisateur dans le processus d'authentification (pour en savoir plus, lisez cet [article](https://web.dev/articles/passkey-form-autofill)).
## 3. Interface conditionnelle (Conditional UI)
L'**interface conditionnelle** (saisie automatique des clés d'accès) affiche les clés d'accès disponibles dans une liste déroulante de sélection pour l'utilisateur, lorsqu'un utilisateur a une clé résidente enregistrée auprès de la partie de confiance. Cela améliore la convivialité des clés d'accès, mais nécessite des efforts de développement supplémentaires et n'est pas disponible pour toutes les combinaisons de systèmes d'exploitation et de navigateurs.
### 3.1 Flux de connexion avec interface conditionnelle
_Comme une connexion classique, l'interface conditionnelle utilise également les objets PublicKeyCredentialRequestOptions et l'assertion._
### 3.2 Compatibilité des appareils
L'interface conditionnelle n'est pas (encore) disponible sur toutes les combinaisons de systèmes d'exploitation et de navigateurs. Voici un aperçu de la couverture actuelle des navigateurs (mars 2024) :
Pour un aperçu à jour, consultez [ce site web.](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static)
### 3.3 Exemples de code
#### 3.3.1 Méthode de l'interface conditionnelle
Un code complet et minimaliste pour une méthode d'interface conditionnelle ressemble à ceci :
```html
Interface conditionnelle
```
#### 3.3.2 Vérification de la compatibilité du navigateur
L'interface conditionnelle ne fonctionne qu'avec les **clés résidentes** / identifiants découvrables.
Il est recommandé de fournir un **point de terminaison de serveur différent** pour lancer la connexion de l'interface conditionnelle.
Le client doit répondre à plusieurs exigences :
- Le navigateur doit prendre en charge l'interface conditionnelle (voir [3.2 Compatibilité des appareils](#device-compatibility)).
- JavaScript doit être activé et la page web doit fournir un champ de saisie HTML.
- Les paramètres de délai d'attente (timeout) doivent être ignorés.
Pour éviter les erreurs, le serveur doit d'abord tester la disponibilité du client avec cette fonction :
Dans le trafic réel, les problèmes de détection et de cycle de vie se manifestent souvent sous la forme de `NotAllowedError` ou `AbortError`. Utilisez ce guide des erreurs WebAuthn pour la classification attendue par rapport à inattendue, y compris les erreurs de clés d'accès natives du gestionnaire d'identifiants.
```javascript
// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
// La disponibilité de `window.PublicKeyCredential` signifie que WebAuthn est utilisable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
// Vérifie si la médiation conditionnelle est disponible.
const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
if (isCMA) {
// Appelle le point de terminaison de démarrage de l'authentification WebAuthn
let options = await WebAuthnClient.getPublicKeyRequestOptions();
const credential = await navigator.credentials.get({
publicKey: options.publicKeyCredentialRequestOptions,
mediation: "conditional",
});
/*
...
*/
}
}
```
#### 3.3.3 Jeton de saisie automatique dans les champs de saisie
Le champ de saisie doit recevoir un jeton de saisie automatique HTML (autofill token), qui signale au client d'ajouter les clés d'accès à la requête en cours. Outre les clés d'accès, les jetons de saisie automatique peuvent être associés à des jetons existants, par exemple des noms d'utilisateur et des mots de passe :
- autocomplete="username webauthn" : En plus d'afficher les clés d'accès, cela suggère également la saisie automatique du nom d'utilisateur.
- autocomplete="current-password webauthn" : En plus d'afficher les clés d'accès, cela demande également la saisie automatique du mot de passe.
```html
```
## 4. Serveur WebAuthn
### 4.1 Schéma de base de données
Il n'y a pas de schéma de base de données obligatoire ou standardisé pour les serveurs WebAuthn. Cependant, cet exemple de schéma de base de données peut être utilisé pour stocker les informations requises et fournir toutes les fonctionnalités d'un serveur WebAuthn :
_Les attributs en gras sont obligatoires pour une implémentation viable minimale, tandis que les autres ne sont nécessaires que pour des fonctionnalités facultatives mais utiles._
#### 4.1.1 Données relatives à l'authentification
- **Credential ID (ID d'identifiant) :** Il s'agit d'un ID unique généré par l'authentificateur lors de l'enregistrement d'une clé d'accès. Il doit être utilisé pour rechercher le compte utilisateur réel associé à la clé d'accès. De plus, le `userHandle` (provenant de `user_id`) doit ensuite être comparé pour valider le compte utilisé pour l'authentification. N'utilisez pas l'attribut `user.name` pour la comparaison car il peut changer au fil du temps.
- **User ID (ID utilisateur - user_id) :** ID unique spécifié par la partie de confiance pour représenter un compte utilisateur dans son système. Il est renvoyé sous la forme de `userHandle` dans l'objet d'assertion.
#### 4.1.2 Métadonnées pour l'affichage et la sélection des clés d'accès :
- **User DisplayName (Nom d'affichage de l'utilisateur - user.displayName) :** Nom lisible et convivial qui correspond généralement au nom complet de l'utilisateur. Il est affiché à l'utilisateur, mais n'est pas utilisé lors de l'authentification.
- **User Name (Nom d'utilisateur - user.name) :** Nom unique et lisible qui correspond généralement à une adresse e-mail ou à un nom d'utilisateur. Il peut être affiché à l'utilisateur, mais il n'est pas utilisé lors de l'authentification.
### 4.2 Identifiant de la partie de confiance (rpId)
L'**identifiant de la partie de confiance (rpID)** est un domaine stocké dans la clé d'accès, garantissant que la clé d'accès ne fonctionne que pour le bon domaine (URL du navigateur, consultez cet article pour les applications natives). Pendant l'authentification, le rpID est vérifié par rapport à l'URL du navigateur et n'est autorisé que dans ces deux cas :
1. L'URL correspond précisément au rpId OU
2. L'URL est un sous-domaine qui correspond au rpId et le domaine parent ne figure pas sur la liste des suffixes publics.
Voici des exemples de combinaisons autorisées et non autorisées :
## 5. Sites web et outils utiles
Voici une liste d'outils et de sites web utiles pour implémenter les clés d'accès.
- [**Débogueur de clés d'accès :**](https://www.passkeys-debugger.io/) Outil pour déboguer les réponses WebAuthn en tant que JSON et tester les opérations WebAuthn avec différentes options.
- **Glossaire des clés d'accès :** Explication des termes et concepts liés aux clés d'accès.
- [**Spécification WebAuthn :**](https://www.w3.org/TR/webauthn-2/) Il s'agit de la spécification WebAuthn officielle.
- [**Chrome Device Log :**](http://chrome://device-log) Outil pour afficher un journal des opérations WebAuthn de votre appareil (uniquement disponible sur Chrome via `chrome://device-log`).
Pour des stratégies d'optimisation de votre expérience utilisateur des clés d'accès au-delà de l'implémentation technique, consultez nos guides sur les meilleures pratiques de création de clés d'accès et les meilleures pratiques de connexion par clé d'accès.
Si vous souhaitez implémenter les clés d'accès avec seulement quelques lignes de code dans n'importe quelle application, vous pouvez également utiliser [Corbado Complete](https://docs.corbado.com/start) (pour les nouvelles applications) ou [Corbado Connect](https://www.corbado.com/enterprise) (pour les applications existantes).
## Foire aux questions
### Comment implémenter l'interface conditionnelle (Conditional UI) pour la saisie automatique des clés d'accès dans mon application web ?
L'interface conditionnelle nécessite de vérifier la prise en charge du navigateur via `PublicKeyCredential.isConditionalMediationAvailable()` avant de lancer l'authentification. Le champ de saisie doit inclure le jeton HTML `autocomplete="username webauthn"` et l'utilisateur doit avoir une clé résidente (identifiant découvrable) enregistrée. Un point de terminaison de serveur distinct est recommandé pour gérer le flux de connexion de l'interface conditionnelle.
### Quelles sont les données minimales que je dois stocker dans ma base de données pour prendre en charge l'authentification WebAuthn ?
Au minimum, stockez l'ID d'identifiant (Credential ID), généré par l'authentificateur lors de l'enregistrement, et l'ID utilisateur (user_id), qui est renvoyé sous la forme de `userHandle` dans l'objet d'assertion. Utilisez l'ID d'identifiant pour rechercher le compte utilisateur associé et comparez le `userHandle` pour valider l'authentification. Évitez d'utiliser `user.name` pour la comparaison car il peut changer au fil du temps.
### Quelle est la différence entre les clés résidentes et non résidentes dans WebAuthn ?
Les clés résidentes (identifiants découvrables) sont stockées sur l'authentificateur lui-même et récupérées lors de l'authentification, ce qui est nécessaire pour que l'interface conditionnelle fonctionne. Les clés non résidentes stockent l'ID d'identifiant sur le serveur et l'envoient à l'authentificateur lors de l'authentification. Le champ `residentKey` dans `authenticatorSelection` contrôle ce comportement avec les valeurs "required", "preferred" ou "discouraged".
### Comment fonctionne userVerification et quels sont les risques de le définir sur preferred ?
Le champ `userVerification` contrôle si l'authentificateur doit vérifier l'utilisateur lors de la connexion, en acceptant les valeurs "required", "preferred" (par défaut) ou "discouraged". Lorsqu'il est défini sur "preferred", l'utilisateur ou son appareil peut ignorer complètement la vérification pendant le processus d'authentification, ce qui peut affaiblir la sécurité. Le définir sur "required" garantit que la vérification a toujours lieu avant la fin de l'authentification.