---
url: 'https://www.corbado.com/fr/blog/cles-acces-liees-appareil-synchronisees'
title: 'Clés d''accès liées à un appareil vs synchronisées (SCA & clés d''accès I)'
description: 'Explorez les clés d''accès synchronisées et liées à un appareil, leurs différences et découvrez le rôle des modules de sécurité matériels (Secure Enclave, TEE, TPM).'
lang: 'fr'
author: 'Vincent Delitz'
date: '2026-05-24T16:30:09.890Z'
lastModified: '2026-10-03T06:03:27.537Z'
keywords: 'clé d''accès liée à un appareil, clé d''accès synchronisée, appareil à clé d''accès, clés d''accès synchronisables'
category: 'Passkeys Strategy'
---

# Clés d'accès liées à un appareil vs synchronisées (SCA & clés d'accès I)

## Aperçu : Authentification forte du client avec les clés d'accès

- Analyse des exigences [DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2) (PSD2) et SCA
- Ce que les exigences SCA signifient pour les [clés d'accès](https://www.corbado.com/fr/glossary/cda)
- Implications de la DSP3 / du [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) pour les
  [clés d'accès](https://www.corbado.com/fr/glossary/cda)

## 1. Introduction : Clés d'accès liées à un appareil vs synchronisées

Dans notre précédent article de blog sur les [clés d'accès](https://www.corbado.com/fr/glossary/cda) et la
[DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2), nous avons discuté de la manière dont les clés d'accès
sont déjà utilisées par des Fintechs comme [Revolut](https://www.corbado.com/blog/revolut-passkeys) et
[Finom](https://www.corbado.com/blog/finom-passkeys), et comment elles améliorent la sécurité numérique dans le
[secteur bancaire](https://www.corbado.com/passkeys-for-banking).

Les clés d'accès se présentent sous deux formes principales : les **clés d'accès
synchronisées** et les **clés d'accès liées à un appareil**. Alors que les clés d'accès
synchronisées permettent aux utilisateurs de s'authentifier de manière transparente sur
plusieurs appareils, les **clés d'accès liées à un appareil** sont strictement associées à
un appareil à [clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) comme une clé
de sécurité matérielle ou un authentificateur local.

Avec cette série de quatre articles de blog, nous souhaitons analyser en profondeur
comment les différents types de clés d'accès (liées à un appareil vs synchronisées)
respectent les exigences SCA et [DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2).

La première partie de cette série est consacrée à la compréhension de la **différence
entre les clés d'accès liées à un appareil et synchronisées**.

La deuxième partie explique de manière compréhensible ce que signifient la DSP2 et
l'[Authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) du client (SCA), en exposant également
leur développement historique.

La troisième partie de la série montre comment les différents types de clés d'accès sont
conformes à la SCA et ce que cela signifie pour les banques, les fintechs et les
institutions financières qui envisagent d'adopter les clés d'accès.

La quatrième et dernière partie de la série conclut sur ce que la DSP3 / le
[PSR](https://www.corbado.com/blog/psd3-psr-passkeys) signifieront pour la SCA et les clés d'accès à l'avenir.

## 2. Authentification forte du client, DSP2 et clés d'accès

À la suite de la publication de notre dernier article de blog, nous avons reçu de
nombreuses questions concernant notre position sur les clés d'accès, spécifiquement en
relation avec la SCA dans le cadre de la DSP2. Il y a un intérêt évident à comprendre non
seulement l'application des clés d'accès, mais aussi comment elles s'alignent sur les
**Normes techniques de réglementation (RTS)**. De plus, les parties prenantes sont
curieuses des interprétations potentielles et des orientations des régulateurs, y compris
l'**Autorité bancaire européenne (ABE)**, concernant l'utilisation des clés d'accès.

Conscients de cela, nous visons à approfondir la façon dont les clés d'accès peuvent être
intégrées dans la directive DSP2, les RTS sur la SCA et à clarifier notre position quant à
l'utilisation de cette technologie. Nous explorerons également les questions et réponses
existantes de l'ABE pour mettre en lumière la façon dont les régulateurs et l'ABE
pourraient percevoir les clés d'accès. Cet examen abordera non seulement les distinctions
entre les clés d'accès synchronisées et liées à un appareil, mais aussi leurs applications
pratiques pour améliorer à la fois la sécurité et l'expérience utilisateur.

En comprenant ces nuances, les parties prenantes peuvent prendre des décisions éclairées
qui non seulement respectent les exigences strictes de la DSP2, mais exploitent également
la dernière technologie
d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) pour sécuriser les
transactions numériques. Notre discussion vise à éclairer davantage la voie vers
l'intégration des clés d'accès dans les processus
d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys), en veillant à ce
que les mesures de sécurité suivent le rythme de l'évolution du paysage numérique.

Bien entendu, chaque entité réglementée soumise à la DSP2 doit prendre ses propres
décisions sur la manière de satisfaire aux objectifs réglementaires, car chaque
[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) a ses propres complexités. Cette
approche individuelle reconnaît que, bien que le cadre réglementaire fournisse une norme
uniforme, l'application pratique de ces normes variera considérablement d'une organisation
à l'autre en raison de leurs environnements opérationnels, de leurs capacités
technologiques et de leurs bases d'utilisateurs uniques.

Ainsi, bien que nos informations visent à guider et à informer, elles ne sont pas
prescriptives. Chaque entité doit tenir compte de ses circonstances et défis spécifiques
lors de l'intégration des clés d'accès dans ses protocoles de sécurité et
d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys).

[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)

## 3. Des clés d'accès liées à un appareil aux clés d'accès synchronisées

Afin de comprendre la différenciation entre les clés d'accès liées à un appareil et
synchronisées, nous explorerons brièvement comment l'écosystème s'est développé.

### 3.1 Que sont les clés d'accès liées à un appareil (clés d'accès sur appareil unique) ?

Nous commençons par examiner l'histoire et l'évolution des clés d'accès liées à un
appareil avant d'examiner plus en profondeur leurs détails techniques.

![Clé d'accès liée à un appareil](https://www.corbado.com/website-assets/device_bound_passkey_effe25ab99.png)

#### 3.1.1 Histoire des clés d'accès liées à un appareil

Historiquement, les mécanismes d'authentification au sein de WebAuthn (la norme
sous-jacente aux clés d'accès) étaient étroitement couplés aux appareils physiques : les
clés de sécurité (par ex. YubiKeys). Avant l'adoption généralisée des clés d'accès,
[les identifiants FIDO2 liés à un seul authentificateur représentaient la référence absolue](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn)
en matière de sécurité. Ces identifiants sont liés à l'appareil sur lequel ils résident.
L'implication de cette liaison était significative : l'identifiant ne pouvait pas être
transféré ou utilisé en dehors de son matériel d'origine.

Cette approche, bien qu'améliorant la sécurité en localisant le processus
d'authentification sur un seul appareil, rencontrait inévitablement des limites pratiques
qui affectaient son adoption généralisée, en particulier par le grand public non
technique. Les utilisateurs étaient obligés d'avoir leur appareil d'authentification
disponible pour chaque tentative de
[connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee), ce qui non seulement
limitait la mobilité de l'utilisateur, mais soulevait également des inquiétudes dans les
scénarios où l'appareil était perdu, endommagé ou pas immédiatement accessible.

En outre, il y avait aussi une réticence des consommateurs à investir dans du matériel
supplémentaire. Historiquement, la possession et l'utilisation de clés de sécurité dédiées
ont été très faibles parmi les consommateurs grand public. La perspective d'acheter un
matériel spécialisé à des fins d'authentification, malgré ses avantages accrus en matière
de sécurité, n'a pas trouvé d'écho favorable auprès de la majorité des utilisateurs B2C,
qui sont par ailleurs souvent la cible de vastes campagnes de
[phishing](https://www.corbado.com/glossary/phishing) ou d'attaques de
[bourrage d'identifiants](https://www.corbado.com/fr/blog/mots-de-passe-complexes-bientot-craques) (credential
stuffing).

#### 3.1.2 Détails techniques des clés d'accès liées à un appareil

Les **clés d'accès liées à un appareil** se caractérisent par leur classification
spécifique en identifiants découvrables et non découvrables, une distinction définissant
principalement leur découvrabilité. Mais le facteur clé qui distingue les **clés liées à
un appareil** est encapsulé dans les propriétés des identifiants WebAuthn, en particulier
via les indicateurs `isBackupEligible` et `isBackupSynchronized`. Pour les **clés d'accès
liées à un appareil**, ces deux champs sont mis à zéro, indiquant que les identifiants ne
sont pas éligibles pour une sauvegarde ou une synchronisation entre appareils. Ces
caractéristiques soulignent leur lien intrinsèque avec l'appareil physique sur lequel ils
ont été créés, garantissant que l'identifiant reste lié à et utilisable uniquement sur
cette pièce de matériel spécifique.

Un exemple notable d'identifiants liés à un appareil dans la pratique est observé dans
l'écosystème [Windows](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android). Les
identifiants [Windows Hello](https://www.corbado.com/glossary/windows-hello) sur
[Windows](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) 10 et
[Windows 11](https://www.corbado.com/blog/passkeys-windows-11) restent liés à
l'appareil—[Windows Hello](https://www.corbado.com/glossary/windows-hello) lui-même ne synchronise pas encore les
clés d'accès entre les appareils. Cependant, Microsoft a fait un premier pas important en
[introduisant la sauvegarde et la synchronisation des clés d'accès dans Microsoft Edge](https://blogs.windows.com/msedgedev/2025/11/03/microsoft-edge-introduces-passkey-saving-and-syncing-with-microsoft-password-manager/)
(à partir d'Edge 142). Cette synchronisation au niveau du navigateur via Microsoft
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) permet aux clés d'accès de se
synchroniser sur les appareils
[Windows](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) lors de
l'utilisation d'Edge, de manière similaire à la façon dont
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) permet la
synchronisation des clés d'accès dans le navigateur Chrome sur Windows. Cela représente
une avancée importante dans les capacités des clés d'accès sous Windows, bien que ce soit
spécifique au navigateur Edge plutôt qu'à l'authentificateur de plateforme
[Windows Hello](https://www.corbado.com/glossary/windows-hello). Les clés d'accès Windows Hello restent liées à
un appareil, mais cette intégration d'Edge offre un chemin pratique vers des clés d'accès
synchronisées sur Windows, tandis que l'authentificateur de plateforme lui-même pourrait
évoluer pour prendre en charge la synchronisation à l'avenir.

D'autre part, Google a formulé une position claire concernant les clés d'accès non
découvrables, indiquant que les clés d'accès non découvrables existantes pourront rester
non synchronisées dans les implémentations futures. Cette décision s'aligne sur le
principe plus large selon lequel les identifiants non découvrables jouent un rôle crucial
dans certains contextes de sécurité en restant strictement liés à un appareil, et n'étant
pas découvrables, ils ne peuvent donc pas être utilisés comme clés d'accès.

À l'inverse, l'approche adoptée par
[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) avec macOS et
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) diffère considérablement. Contrairement à la
stratégie fixe et liée à un appareil observée avec Windows et les clés non découvrables de
Google,
[l'écosystème d'Apple penche beaucoup plus fortement vers la seule autorisation de clés d'accès synchronisées, en particulier sur iOS](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/),
rendant ainsi impossible la création de clés d'accès liées à un appareil via WebAuthn.

Cette segmentation des stratégies sur les principales plateformes illustre les diverses
approches de la gestion des identifiants WebAuthn, en particulier lorsqu'on considère
l'équilibre entre la sécurité, la commodité et l'accessibilité pour les utilisateurs.
Alors que les clés d'accès liées à un appareil offrent un niveau de sécurité élevé en
garantissant que les identifiants ne peuvent pas être déplacés ou utilisés de manière
abusive en dehors de l'appareil auquel ils sont destinés, l'industrie continue d'évoluer,
recherchant des solutions qui maintiennent les normes de sécurité sans compromettre
l'expérience et la mobilité de l'utilisateur.

### 3.2 Que sont les clés d'accès synchronisées (clés d'accès multi-appareils) ?

Ici aussi, nous examinons le développement historique des clés d'accès synchronisées avant
d'analyser les détails techniques. Les clés d'accès synchronisées sont parfois aussi
appelées **clés d'accès synchronisables**.

![Clé d'accès synchronisée](https://www.corbado.com/website-assets/synced_passkey_042125aca6.png)

#### 3.2.1 Histoire des clés d'accès synchronisées

À la suite de la publication des spécifications WebAuthn Level 2 et
[CTAP](https://www.corbado.com/fr/glossary/ctap) 2.1 vers le milieu à la fin de 2021, le groupe de travail
WebAuthn a lancé une initiative industrielle importante visant à surmonter les principaux
obstacles empêchant la norme WebAuthn de remplacer les mots de passe et d'augmenter son
adoption. Cette initiative s'est concentrée sur deux
[domaines](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) critiques : éliminer la
nécessité d'appareils de sécurité matériels supplémentaires et atténuer le risque associé
à la perte de l'authentificateur tout en gardant une compatibilité ascendante complète
avec les normes existantes.

##### 3.2.1.1 Utilisation des authentificateurs de plateforme comme modules matériels sécurisés

Le premier défi – éradiquer le besoin de nouveau matériel – a été relevé grâce à
l'utilisation des
[authentificateurs de plateforme](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) intégrés
que l'on trouve dans les appareils grand public modernes (par ex. Touch ID,
[Face ID](https://www.corbado.com/faq/is-face-id-passkey), Windows Hello).

![Modules de sécurité matériels HSM TPM TEE Secure Enclave](https://www.corbado.com/website-assets/hardware_security_modules_hsm_tpm_tee_secure_enclave_11118d359e.png)

Les appareils modernes sont de plus en plus équipés de modules de sécurité spécialisés,
tels que le Trusted Execution Environment (TEE) sur
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), le
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) et
macOS, et le Trusted Platform Module (TPM) sur les appareils Windows. Ces magasins de clés
de sécurité intégrés servent de base robuste aux clés d'accès, fonctionnant efficacement
comme des "clés de sécurité" intégrées. Cette approche permet l'adoption généralisée de la
cryptographie à clé publique, un niveau de sécurité auparavant accessible uniquement par
des
[clés de sécurité matérielles](https://www.corbado.com/fr/blog/meilleures-cles-securite-materielles-fido2-2026)
externes (par ex. YubiKeys), et largement limité aux individus technophiles ou aux
organisations au sein d'industries hautement réglementées.

En exploitant les capacités du TEE, de [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) ou du
TPM, les protocoles WebAuthn sont capables de fournir des mécanismes d'authentification
utilisateur cryptographiques forts. Désormais, des méthodes d'authentification
sophistiquées sont rendues conviviales et accessibles au grand public, sans avoir besoin
de matériel supplémentaire spécialisé.

Cette évolution est une amélioration très forte de l'approche de la sécurité numérique,
soulignant le rôle critique que jouent les solutions de sécurité centrées sur
l'utilisateur dans la stimulation d'une adoption généralisée. Les organisations qui
combinent les clés d'accès synchronisées avec une création de clés d'accès optimisée et
des flux de [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) par
[clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) voient les taux d'adoption
les plus élevés. En utilisant les fonctionnalités de sécurité des appareils contemporains,
l'effort de l'industrie a franchi avec succès le premier obstacle consistant à supprimer
la nécessité d'un matériel externe.

Ce développement a été une étape cruciale dans une nouvelle ère de l'écosystème
d'authentification numérique, où l'application large de la cryptographie à clé publique
devient directement applicable à un large éventail de cas d'utilisation et simplifie en
même temps l'authentification pour les utilisateurs.

##### 3.2.1.2 Synchronisation des clés d'accès dans le cloud

Afin de traiter le risque lié à la perte du téléphone mobile et, par extension, des clés
d'accès qui y sont stockées, l'initiative de l'industrie s'est concentrée sur la
synchronisation des identifiants découvrables avec le cloud. Cette approche a efficacement
transformé les identifiants, qui étaient strictement liés à un appareil, en des
identifiants multi-appareils, et plus précisément, liés au compte de l'utilisateur auprès
de son fournisseur de cloud, comme iCloud pour les appareils
[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) ou Google pour les
appareils [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android).

Cette solution pratique signifiait que même si le téléphone d'un utilisateur était perdu
ou remplacé, les identifiants établis précédemment ne seraient pas perdus de façon
permanente. Au lieu de cela, ces identifiants pouvaient être récupérés à partir du compte
cloud de l'utilisateur et synchronisés sur un nouvel appareil. Ce changement a
considérablement réduit les désagréments et les risques de sécurité précédemment associés
à la perte d'un authentificateur physique.

En tirant parti de la synchronisation cloud, les clés d'accès pouvaient désormais passer
de manière transparente d'un appareil de l'utilisateur à un autre, en conservant leur
intégrité et leur sécurité quel que soit l'appareil spécifique utilisé. Par exemple,
lorsqu'un utilisateur se connecte à un site Web à partir d'un nouvel appareil, les
identifiants disponibles dans son compte cloud peuvent être automatiquement suggérés pour
l'authentification. Si nécessaire, ces identifiants peuvent être transmis au nouvel
appareil, maintenant une expérience d'authentification cohérente et sécurisée sur
différentes plateformes et appareils.

Cette transition vers des identifiants liés à un compte et synchronisés dans le cloud
représente une approche pragmatique de la sécurité numérique. Elle reconnaît les réalités
de l'utilisation des appareils modernes et la fréquence courante des échanges d'appareils,
que ce soit à la suite d'une perte, d'un dommage ou d'une mise à niveau. En liant les
identifiants au compte cloud de l'utilisateur – que ce soit avec iCloud
d'[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) ou les services
cloud de Google – la solution ne se contente pas d'atténuer le risque associé à la perte
d'un appareil, elle améliore également la capacité de l'utilisateur à gérer et à récupérer
son [identité numérique](https://www.corbado.com/fr/glossary/openid-4-vp) sur plusieurs appareils.

Ce développement élargit efficacement l'applicabilité des mécanismes d'authentification
cryptographiques forts de WebAuthn, les rendant plus adaptables aux scénarios
d'utilisation réels. Il garantit également qu'une
[authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) est accessible et gérable, non seulement
pour ceux qui ont une formation technique ou ceux dans des secteurs hautement réglementés,
mais pour l'utilisateur moyen naviguant dans le monde numérique avec plusieurs appareils.

#### 3.2.2 Détails techniques des clés d'accès synchronisées

Les clés d'accès synchronisées sont également connues sous le nom d'identifiants
découvrables ou de clés résidentes. Elles se distinguent des clés liées à un appareil par
deux propriétés critiques : `isBackupEligible` et `isBackedUp` ont des valeurs
différentes. Pour les clés d'accès synchronisées, l'indicateur `isBackupEligible` est
défini sur 1, ce qui indique que ces identifiants sont éligibles pour la sauvegarde. Lors
d'une synchronisation réussie sur le cloud, l'indicateur `isBackedUp` est également défini
sur 1, confirmant que l'identifiant a été correctement synchronisé. Il est important de
noter que le statut de synchronisation peut changer avec le temps, reflétant la nature
dynamique de l'utilisation et de la gestion des appareils.

Lorsque les plateformes demandent des clés résidentes, en définissant le paramètre
"requireResidentKey" sur **required** ou **preferred**, les plateformes qui prennent en
charge les services cloud créent automatiquement des clés d'accès synchronisées. Ce
processus garantit que les utilisateurs peuvent compter sur l'accessibilité de leurs
identifiants sur leurs différents appareils. Sous Windows, les clés d'accès synchronisées
sont désormais disponibles via Microsoft Edge / Microsoft
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) (synchronisation au niveau du
navigateur), tandis que les identifiants de l'authentificateur de plateforme Windows Hello
restent liés à un appareil. Les
[gestionnaires de mots de passe tiers](https://www.corbado.com/fr/blog/test-passkeys-applications-natives-gestionnaires-mots-de-passe-tiers)
(par ex. [Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [KeePassXC](https://www.corbado.com/blog/keepassxc-passkeys),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) disposant de capacités de
gestion des clés d'accès offrent également une synchronisation inter-plateformes. Dans les
scénarios où des clés d'accès synchronisées sont utilisées, les indicateurs
`isBackupEligible` et `isBackedUp` sont mis à 1, indiquant l'éligibilité à la sauvegarde
et la réussite de la synchronisation.

En outre, bien qu'il soit actuellement encore possible d'identifier l'authentificateur
spécifique où la [clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) a été
stockée, l'absence d'[attestation](https://www.corbado.com/glossary/attestation) pour la majorité de ces
identifiants signifie que leur origine ne peut pas être vérifiée de manière
cryptographique. Cet aspect met en évidence une limitation potentielle dans la garantie de
la provenance de sécurité des clés d'accès synchronisées uniquement via les mécanismes
standards de WebAuthn.

Ce développement des clés d'accès synchronisées élargit essentiellement la portée des
identifiants découvrables en les intégrant dans un framework de synchronisation basé sur
le cloud. En rendant ces clés éligibles à la sauvegarde et en assurant leur
synchronisation sur les appareils d'un utilisateur, WebAuthn résout deux des principaux
défis de l'authentification numérique : le risque de perte d'accès due à la perte
d'appareils et le désagrément de la gestion de multiples identifiants liés à un appareil.

### 3.3 Liaison à un seul appareil des identifiants WebAuthn sacrifiée pour le bien commun

La transition des clés d'accès liées à un appareil aux clés d'accès synchronisées a ouvert
un dialogue critique au sein du groupe de travail WebAuthn, centré sur la nécessité de
mesures de sécurité avancées, les questions juridiques impliquées et un compromis à la
fois convivial pour le consommateur et sécurisé.

L'[adoption des clés d'accès](https://www.corbado.com/fr/blog/analyse-rentabilite-adoption-passkeys)
synchronisées a été célébrée pour sa promesse d'améliorer la commodité et la sécurité des
utilisateurs grâce à des fonctionnalités telles que la synchronisation dans le cloud et la
fonctionnalité transparente multi-appareils. Cependant, elle a introduit un certain
malaise parmi certaines parties de confiance (RP), en particulier concernant les
implications pour la sécurité et la conformité dans des environnements avec des exigences
élevées. L'essence du débat résidait dans la nécessité d'un mécanisme garantissant que
même les clés d'accès synchronisées conservaient une
[connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) à des appareils spécifiques,
un concept crucial pour les parties de confiance traitant des transactions sensibles ou
opérant sous des normes réglementaires strictes.

Pour les RP incapables ou ne souhaitant pas adopter de clés d'accès, l'absence d'une
méthode fiable pour lier ces identifiants à des appareils spécifiques dans des
applications critiques posait un défi majeur. Un tel mécanisme était considéré comme très
important par certaines RP. Le manque de cette capacité de liaison à un appareil, une
attente qui n'était peut-être pas explicitement formulée mais qui était certainement
espérée, représentait une surprise sérieuse et une rupture de confiance de leur point de
[vue](https://www.corbado.com/blog/vuejs-passkeys).

La discussion a conclu qu'il devrait y avoir une harmonisation des intérêts, mais que dans
un premier temps, le bien commun du déploiement des clés d'accès devrait primer. Dans la
discussion, l'extension [devicePubKey](https://github.com/w3c/webauthn/issues/1658) a été
considérée comme un moyen de répondre à ces préoccupations, mais elle a ensuite été
remplacée par **supplementalPubKeys** qui adopte une approche beaucoup plus large dans la
version préliminaire actuelle de [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn).
Malheureusement, cette approche a également été abandonnée en août 2024.

### 3.4 Le meilleur des deux mondes : Les clés d'accès et l'extension supplementalPubKeys \[obsolète depuis août 2024]

Analysons comment le compromis avec l'extension supplementalPubKeys s'est formé et ce que
cela signifie techniquement.

#### 3.4.1 De devicePubKey à l'extension supplementalPubKeys

La discussion entourant la transition de l'extension **devicePubKey** vers l'extension
**supplementalPubKeys** met en évidence la nature dynamique de la spécification WebAuthn.
Initialement, **devicePubKey** servait à améliorer la sécurité via des clés publiques
liées à un appareil, mais elle a ensuite été remplacée par la suggestion de
**supplementalPubKeys** dans le
[projet de travail de l'éditeur pour WebAuthn Level 3](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension).
Cette nouvelle extension offre une solution plus complète en permettant à de multiples
clés d'améliorer les processus d'authentification.

Le cœur du débat s'est concentré sur l'équilibre entre des mesures de sécurité renforcées
et l'adoption plus large et l'utilité pratique des clés d'accès sur différents appareils
et plateformes. L'extension **supplementalPubKeys** représente une combinaison de ces
priorités, permettant une authentification plus stricte. Par exemple, elle s'adapte aux
réglementations exigeant certaines normes d'authentification en autorisant des "sous-clés"
supplémentaires avec des déclarations d'[attestation](https://www.corbado.com/glossary/attestation). Ces clés
peuvent signaler la conformité aux exigences d'authentification, réduisant potentiellement
le besoin de défis de connexion supplémentaires sous certaines conditions (même avec les
clés d'accès).

[Un exemple tiré directement du brouillon WebAuthn](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension)
:

"_Supposons qu'une demande de connexion apparaisse sur un site Web avec un signal de
géolocalisation qui n'a pas été vu pour ce compte utilisateur auparavant, et qui se situe
en dehors des heures d'utilisation typiques observées pour le compte. Le risque peut être
jugé trop élevé pour autoriser la demande, même avec une assertion par un identifiant
multi-appareils à lui seul. Mais si une signature provenant d'une clé supplémentaire liée
à l'appareil, et qui est bien établie pour cet utilisateur, peut également être présentée,
alors cela pourrait faire pencher la balance._"

Lors de la discussion, il a été souligné que ces fonctionnalités étaient uniquement
destinées aux RP ayant des exigences de sécurité extrêmement élevées (par exemple, dans le
contexte [gouvernemental](https://www.corbado.com/passkeys-for-public-sector)).

En intégrant les retours et en abordant des cas d'utilisation spécifiques – y compris les
transactions financières réglementées et le besoin de signaux liés à un appareil dans un
environnement d'identifiants multi-appareils – la communauté WebAuthn visait à résoudre
les problèmes de sécurité et d'interopérabilité. L'extension **supplementalPubKeys** est
donc une approche qui cherche à fournir des fonctionnalités de sécurité robustes tout en
soutenant l'expérience utilisateur fluide et la large compatibilité essentielles à
l'adoption généralisée des clés d'accès. Il s'agit d'une extension entièrement facultative
qui n'interfère pas avec l'[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) des clés
d'accès telle que nous l'avons connue ces 2 dernières années.

Cette évolution vers un cadre plus inclusif et flexible souligne l'engagement de la
communauté WebAuthn à améliorer les méthodes d'authentification web même pour des cas
d'utilisation plus stricts.

#### 3.4.2 Détails techniques de supplementalPubKeys

L'extension **supplementalPubKeys** introduite dans WebAuthn permet l'utilisation de
paires de clés supplémentaires aux côtés de l'identifiant principal.

![Graphique de clé publique supplémentaire](https://www.corbado.com/website-assets/supplemental_pub_key_chart_b976bf5115.png)_Tiré
du [ticket GitHub original](https://github.com/w3c/webauthn/pull/1957)_

L'image montre le concept de **supplementalPubKey** tiré du
[ticket GitHub original](https://github.com/w3c/webauthn/pull/1957) (pk = clé d'accès,
pspk=clé supplémentaire du fournisseur, dspk = clé supplémentaire de l'appareil).

Voici une décomposition de son fonctionnement et de son utilisation
pré[vue](https://www.corbado.com/blog/vuejs-passkeys) :

**But et fonctionnalité de supplementalPubKey**

- **Un identifiant central de clé d'accès reste :** Il est important de garder à l'esprit
  qu'une seule clé d'accès centrale reste la méthode principale d'authentification de
  l'utilisateur, et les clés supplémentaires fournissent des couches supplémentaires de
  sécurité et d'assurance. Cette structure maintient la simplicité et l'efficacité de
  l'utilisation d'une clé d'accès unique et centrale pour l'authentification sur plusieurs
  appareils, garantissant une expérience utilisateur fluide. Les clés supplémentaires,
  quant à elles, servent à améliorer le contexte d'authentification, offrant à la
  [partie de confiance](https://www.corbado.com/fr/glossary/relying-party) (RP) des signaux supplémentaires
  concernant l'environnement de sécurité ou la conformité à des normes d'authentification
  spécifiques. Ces clés supplémentaires ne sont pas des méthodes d'authentification
  autonomes, mais augmentent plutôt la clé d'accès principale, renforçant sa fiabilité
  avec des preuves de l'intégrité de l'appareil
- **Clés liées à l'appareil (Device-Bound Keys)** : Celles-ci sont liées spécifiquement à
  un seul appareil. Elles peuvent fournir l'assurance qu'une demande d'authentification
  provient d'un appareil de confiance qui a déjà été authentifié. Elles ne seront en aucun
  cas synchronisées.
- **Clés liées au fournisseur (Provider-Bound Keys)** : Ces clés ont une portée
  "fournisseur", ce qui signifie qu'elles peuvent offrir des assurances supplémentaires
  basées sur les politiques du fournisseur d'authentification ou sur
  l'[attestation](https://www.corbado.com/glossary/attestation) spécifique du fournisseur. Par exemple, un
  fournisseur peut n'émettre une telle clé qu'après qu'un utilisateur ait passé un niveau
  supérieur d'authentification (comme l'authentification à deux facteurs ou
  [2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)).
- **Plusieurs clés publiques** : Contrairement à son prédécesseur, l'extension
  **devicePubKey**, qui ne permettait qu'une seule clé publique liée à l'appareil,
  **supplementalPubKeys** permet l'inclusion d'un ou de deux types de clés
  supplémentaires. Ces clés peuvent servir des objectifs et des portées différents – à
  savoir, des portées liées à un appareil et liées à un fournisseur.

**Cas d'utilisation et exemples de supplementalPubKey**

1. **Sécurité renforcée** : Dans les situations où un site Web (partie de confiance) doit
   adhérer à certaines normes de sécurité renforcées pour l'authentification, des clés
   supplémentaires peuvent être utilisées pour répondre à ces exigences. Si cette clé
   supplémentaire a été [vue](https://www.corbado.com/blog/vuejs-passkeys) et vérifiée par le site auparavant,
   elle pourrait permettre à l'utilisateur de contourner des défis de connexion
   supplémentaires, car la continuité de l'appareil peut être confirmée par des signaux
   antérieurs.
2. **Gestion des risques** : Pour les demandes de connexion qui semblent risquées (par
   ex., provenant d'une nouvelle géolocalisation ou à des heures inhabituelles), la
   présence d'une clé supplémentaire liée à un appareil qui a un historique d'utilisation
   avec le compte de l'utilisateur pourrait réduire le risque perçu et permettre de
   poursuivre la demande là où elle aurait pu être bloquée autrement.

**Aspects techniques de supplementalPubKey**

- **Pas d'ID d'identifiant propre :** Les clés supplémentaires ne sont pas des
  identifiants utilisateur et elles n'ont pas leurs propres ID d'identifiant.
- **Déclarations d'attestation** : Les clés supplémentaires peuvent facultativement avoir
  une attestation. Celles-ci sont cruciales pour comprendre la portée et le niveau de
  sécurité des clés supplémentaires. Une attestation peut indiquer le niveau de protection
  dont bénéficie une clé liée au matériel, ou les politiques relatives à d'autres types de
  clés supplémentaires.
- **Mise en œuvre pour les parties de confiance** : Les parties de confiance peuvent
  demander ces clés supplémentaires dans le cadre du processus d'authentification.
  Cependant, la complexité de traiter plusieurs clés et déclarations d'attestation
  signifie que cette extension est la mieux adaptée aux entités ayant des besoins de
  sécurité spécifiques, telles que les banques ou les services opérant sous des exigences
  réglementaires strictes.

Il est crucial de noter que, à la date d'avril 2024, l'extension **supplementalPubKeys**
n'a été adoptée par aucun des principaux navigateurs, et la spécification
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) est encore en cours d'élaboration et
sujette à modifications. La question de savoir si cette fonctionnalité sera incluse dans
la version finale de la spécification, et sa potentielle mise en œuvre et adoption
futures, reste incertaine, car elle n'en est actuellement qu'au stade de brouillon de
l'éditeur.

#### 3.4.3 Dépréciation de supplementalPubKeys en août 2024

Depuis août 2024, l'extension **supplementalPubKeys** a été officiellement abandonnée. Le
groupe de travail WebAuthn a décidé de retirer cette fonctionnalité en raison d'un support
insuffisant. La dépréciation de cette extension met également en évidence une nouvelle
direction. Actuellement, l'**Alliance FIDO** travaille sur le développement d'une approche
différente pour soutenir les **Parties de confiance** ayant des exigences de sécurité
élevées. Cette solution à venir devrait combler les lacunes laissées par l'arrêt de
**supplementalPubKeys** et offrir de nouvelles méthodes pour renforcer les processus
d'authentification dans des scénarios où des normes de sécurité strictes sont critiques.

Pour plus de détails sur la dépréciation, consultez la
[pull request officielle sur GitHub de WebAuthn](https://github.com/w3c/webauthn/pull/2109).

## 4. Comment Corbado gère les différences entre les clés d'accès liées à un appareil et synchronisées dans la pratique

Comprendre la différence entre les clés d'accès liées à un appareil et synchronisées est
une chose. Savoir lesquelles vos propres utilisateurs détiennent réellement en est une
autre, et la réponse bouge sans arrêt à mesure que les plateformes et les gestionnaires de
mots de passe changent de comportement. [Corbado Observe](https://www.corbado.com/observe) est la couche
d'[observabilité de l'authentification](https://www.corbado.com/fr/blog/observabilite-authentification), et elle
dérive cette répartition des données de credentials elles-mêmes plutôt que de ce qu'un
utilisateur croit utiliser.

### Visibilité du type de clé d'accès sur toute votre base d'utilisateurs

La vue [Authenticator](https://www.corbado.com/glossary/authenticator) Inventory classe chaque credential de
votre base d'utilisateurs comme clé d'accès synchronisée, clé d'accès liée à un appareil
ou clé de sécurité itinérante. La classification s'appuie sur des signaux produits par la
cérémonie elle-même : les transports annoncés par le credential, le bit backup state
décodé depuis l'[assertion](https://www.corbado.com/glossary/assertion) et l'[AAGUID](https://www.corbado.com/glossary/aaguid) rapproché
du FIDO Metadata Service. Les credentials dont les signaux ne se résolvent pas restent
étiquetés inconnus, et chaque classification porte un niveau de confiance, de sorte qu'un
ancien enregistrement lacunaire ne devient pas silencieusement une statistique.

[Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory))

La même vue contient le statut de certification FIDO par modèle d'authentificateur et une
tendance mensuelle du mélange, ce qui rend visible qu'une population glisse des
credentials liés à l'appareil vers des credentials synchronisés alors que personne de
votre côté n'a rien changé. La section 3.4 explique pourquoi supplementalPubKeys a été
retirée. La conséquence pratique est que les flags backup eligibility et backup state sont
le signal par credential le plus solide qui reste, et Observe décode les deux à partir de
chaque [assertion](https://www.corbado.com/glossary/assertion).

### Ce que cela vous apporte pour la discussion sur l'AFC

Le type de clé d'accès est une entrée d'une évaluation des risques, et une évaluation a
besoin de preuves en dessous. Observe enregistre également le flag
[user verification](https://www.corbado.com/blog/webauthn-user-verification) de chaque
[assertion](https://www.corbado.com/glossary/assertion), si bien que « une
[biométrie](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) ou un code PIN a été
effectué » est une valeur dans vos propres données plutôt qu'une déduction à partir des
options de cérémonie que vous avez envoyées.

Agir sur la différence au moment du prompt passe par l'environnement, qui est ce qui est
observable avant qu'un credential existe. [Corbado Connect](https://www.corbado.com/connect) évalue le web face à
l'[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys), la
[WebView](https://www.corbado.com/blog/native-app-passkeys), la version de plateforme, la marque et le modèle de
l'appareil et la disponibilité de [conditional create](https://www.corbado.com/blog/conditional-create-passkeys)
lorsqu'il décide d'afficher ou non un prompt de clé d'accès, et ses règles de déploiement
utilisent les mêmes conditions pour contrôler quelles cohortes atteignent le flux de clés
d'accès.

> **Position de Corbado sur la DSP2/SCA et les clés d'accès :** Les clés d'accès (à la
> fois liées à un appareil et synchronisées) peuvent être conformes à la SCA. Chaque
> institution doit s'approprier son évaluation des risques SCA, mais les preuves sont
> claires : les clés d'accès fournissent par essence deux facteurs SCA - la possession
> (clé privée dans un module de sécurité matériel ou un trousseau cloud) + inhérence
> (biométrie) ou connaissance (code PIN). Le débat sur la "possession" est nuancé mais
> résoluble - l'industrie s'oriente vers trois approches : (1) **Les clés d'accès telles
> quelles** (par ex. [Revolut](https://www.corbado.com/blog/revolut-passkeys), [Finom](https://www.corbado.com/blog/finom-passkeys)) -
> inhérence + possession via l'appareil avec la clé privée, (2) **Clés d'accès + liaison à
> un cookie/une session** (par ex. [PayPal](https://www.corbado.com/blog/paypal-passkeys), Comdirect) - signal de
> possession supplémentaire pour une interprétation prudente, (3) **Liaison
> cryptographique (DBSC/DPoP)** - preuve de possession liée au matériel, la garantie la
> plus forte. Il n'existe pas encore d'interprétation "correcte" unique. Une approche de
> la SCA basée sur les résultats est nécessaire - se concentrant sur une résistance
> prouvée au [phishing](https://www.corbado.com/glossary/phishing) plutôt que sur une catégorisation rigide des
> facteurs. La [liaison dynamique](https://www.corbado.com/fr/blog/liaison-dynamique-passkeys-spc) reste une
> exigence distincte pour les [paiements](https://www.corbado.com/passkeys-for-payment) même avec des clés
> d'accès.

## Foire aux questions

### Comment les clés d'accès liées à un appareil améliorent-elles la sécurité ?

Les clés d'accès liées à un appareil sont des identifiants WebAuthn strictement liés à
l'appareil sur lequel elles ont été créées. Contrairement aux clés d'accès synchronisées,
elles restent sur un seul appareil, ce qui les rend intrinsèquement plus sécurisées pour
certains cas d'utilisation :

- **Pas de vol d'identifiant** : La clé privée ne quitte jamais l'appareil, de sorte que
  les attaquants ne peuvent pas intercepter les identifiants.
- **Prévention de l'accès non autorisé** : L'authentification n'a lieu que depuis
  l'appareil spécifique où la clé d'accès a été créée.
- **Pas de dépendance au cloud** : Élimine les risques associés aux violations de données
  cloud ou aux prises de contrôle de compte.
- **Conformité à une sécurité élevée** : Répond aux exigences strictes d'authentification
  liée à un appareil pour des industries réglementées comme les
  [services financiers](https://www.corbado.com/passkeys-for-banking) (AAL3).

Le principal inconvénient est la portabilité limitée. Si l'appareil est perdu, la clé
d'accès ne peut pas être récupérée à moins que l'utilisateur n'en enregistre une nouvelle
sur un autre appareil.

### Pourquoi les clés d'accès synchronisées ont-elles été introduites et quels sont leurs avantages ?

Les clés d'accès synchronisées (clés d'accès multi-appareils) ont été introduites pour
résoudre les problèmes d'utilisation des clés d'accès liées à un appareil, notamment le
manque de portabilité et le verrouillage potentiel du compte si un appareil est perdu. Les
principaux avantages comprennent :

- **Authentification multi-appareils** : Accéder à des comptes à partir de plusieurs
  appareils sans enregistrer manuellement une nouvelle clé d'accès pour chacun d'eux.
- **Aucun risque de perdre l'accès** : Les identifiants sont sauvegardés dans le cloud
  (par ex. [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)), ce qui garantit la
  récupération si un appareil est perdu.
- **Amélioration de l'expérience utilisateur** : Élimine la friction en supprimant le
  besoin de transférer manuellement ou de recréer les identifiants.
- **Pas besoin de matériel supplémentaire** : Contrairement aux clés de sécurité
  matérielles, les clés d'accès synchronisées utilisent les modules de sécurité intégrés
  de l'appareil.
- **Une forte sécurité avec la commodité du cloud** : Le chiffrement de bout en bout
  garantit que la clé privée ne quitte jamais l'appareil sous un format non chiffré.

## 5. Conclusion

Dans la première partie de notre série en 4 volets, nous avons analysé quelles sont les
différences historiques et techniques des clés d'accès liées à un appareil et
synchronisées. Comprendre ces différences nous aidera à appliquer les exigences de la DSP2
et de la SCA en conséquence. Nous avons également jeté un coup d'œil à ce que l'avenir
pourrait réserver en observant les derniers changements dans la norme
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) toujours en évolution.

Voici les liens vers les autres parties de notre série :

- Partie 2 "Analyse des exigences DSP2 et SCA (SCA & clés d'accès II)"
- Partie 3 "Ce que les exigences SCA signifient pour les clés d'accès (SCA & clés d'accès
  III)"
- Partie 4 "Implications de la DSP3 / du [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) pour les clés
  d'accès (SCA & clés d'accès IV)"