---
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-05-24T16:35:30.765Z'
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 (PSD2) et SCA
- Ce que les exigences SCA signifient pour les clés d'accès
- Implications de la DSP3 / du PSR pour les clés d'accès

## 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 et la 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 et Finom, 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 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.

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 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 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 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, 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 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.

[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, 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 ou d'attaques de bourrage d'identifiants (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. Les identifiants Windows Hello sur Windows 10 et Windows 11 restent liés à l'appareil—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 permet aux clés d'accès de se synchroniser sur les appareils Windows lors de l'utilisation d'Edge, de manière similaire à la façon dont 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. 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 avec macOS et 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 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 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 intégrés que l'on trouve dans les appareils grand public modernes (par ex. Touch ID, Face ID, 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, le Secure Enclave sur 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 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 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 par clé d'accès 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 ou Google pour les appareils 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 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 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 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 (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 (par ex. Dashlane, KeePassXC, 1Password) 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 a été stockée, l'absence d'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 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 à 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.

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. 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. 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 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 :

**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 (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 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).
- **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 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 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 les différences entre les clés d'accès liées à un appareil et synchronisées est essentiel, mais les banques ont également besoin d'outils pour opérationnaliser ces différences à grande échelle. La plateforme de Corbado fournit une intelligence de confiance sur l'appareil qui classifie automatiquement les types de clés d'accès et applique le traitement SCA approprié à chacun.

### Visibilité de la confiance de l'appareil selon les types de clés d'accès

Le tableau de bord Device Trust de Corbado montre comment les clés d'accès liées à un appareil et celles synchronisées performent différemment en production. Les clés d'accès liées à un appareil atteignent des taux de réussite plus élevés (99,1 %) avec zéro exigence de renforcement (step-up), tandis que les clés d'accès synchronisées dotées de signaux de confiance sur l'appareil atteignent 98,4 % avec un léger taux de renforcement pour les nouveaux appareils.

![Tableau de bord Device Trust de Corbado](https://www.corbado.com/website-assets/corbado_device_trust_dashboard_42ce934484.png)

Le tableau de bord suit également la classification des appareils — identifiant quels appareils sont exclusifs à un seul utilisateur (92 % dans les déploiements typiques dans le [secteur bancaire](https://www.corbado.com/passkeys-for-banking)), lesquels sont partagés entre deux utilisateurs (7 %) et lesquels sont des appareils partagés/en kiosque (0,8 %). Cette classification alimente directement les décisions de conformité SCA.

### Contrôle basé sur des politiques pour différents scénarios de clés d'accès

Au lieu de traiter toutes les clés d'accès de la même manière, les politiques de confiance de Corbado permettent aux banques d'appliquer des règles différentes en fonction du type de clé d'accès, du statut de l'appareil et du niveau de confiance. Les clés d'accès liées à un appareil sur des appareils connus bénéficient d'une authentification sans friction, tandis que les clés d'accès synchronisées sur de nouveaux appareils déclenchent une vérification renforcée (step-up) — exactement le type d'approche nuancée que le cadre SCA de la DSP2 exige.

![Configuration des politiques de confiance de Corbado](https://www.corbado.com/website-assets/corbado_trust_policy_80ad56409f.png)

Cela signifie que les banques peuvent déployer en toute confiance des clés d'accès synchronisées pour une meilleure expérience utilisateur tout en maintenant le contrôle strict des appareils que les clés d'accès liées à un appareil fournissent pour des scénarios de haute sécurité — tout cela géré par la configuration de politiques plutôt que par des flux d'authentification séparé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, Finom) - 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, 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 plutôt que sur une catégorisation rigide des facteurs. La liaison dynamique 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, 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 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 pour les clés d'accès (SCA & clés d'accès IV)"