Clés d'accès dans le navigateur Brave (2026) : Ce qui fonctionne et ce qui casse

1. Introduction : Prise en charge des clés d'accès dans Brave aujourd'hui#

La prise en charge des clés d'accès par Brave est proche de Chromium au niveau du code, mais l'expérience utilisateur diverge à quelques endroits importants. En avril 2026, le dépôt plus large brave/brave-browser comportait encore 24 problèmes ouverts correspondant à passkey ou WebAuthn, tandis que brave/brave-core affichait une seule personnalisation visible spécifique à WebAuthn. Les principaux points de rupture sont l'interception par les extensions, les invites Windows Hello et les flux Android sur les appareils dé-Googleisés.

Brave déploie les clés d'accès via le même chemin de code WebAuthn que le projet Chromium en amont et délègue le stockage des identifiants au système d'exploitation. Cette architecture donne à Brave une apparence standard sur le papier, mais le comportement réel dépend toujours des systèmes environnants tels que les extensions de gestionnaires de mots de passe, Windows Hello et les Services Google Play. Les sections ci-dessous séparent ces modes de défaillance afin que chaque comportement spécifique à la plateforme puisse être compris en lui-même.

2. En quoi la pile WebAuthn de Brave diffère-t-elle de celle de Chromium ?#

L'implémentation de WebAuthn dans Brave est en fait l'implémentation de Chromium avec un seul changement de texte visible dans l'interface utilisateur. Le dépôt brave/brave-core contient une seule personnalisation liée à WebAuthn - un remplacement de chaîne qui renomme « Incognito » en « Private » dans la boîte de dialogue d'enregistrement - et aucun correctif C++ touchant à la logique principale de WebAuthn. Cela signifie que Brave hérite de la pile de clés d'accès Chromium que Google a publiée à partir de Chromium 115 en juin 2023.

Ceci est important pour deux raisons. Premièrement, les fusions normales en amont signifient que les correctifs WebAuthn et les ajouts de fonctionnalités arrivent généralement sans que Brave n'entretienne une implémentation de clés d'accès profondément dérivée (fork). Vous pouvez inspecter le seul remplacement de chaîne directement dans brave/brave-core. Dans les mappages AAGUID, le chemin de l'authentificateur de navigateur Chromium est couramment identifié comme b5397666-4885-aa6b-cebf-e52262a439a2, étiqueté « Chromium Browser » dans notre liste de référence. Deuxièmement, la plupart des échecs signalés - interception d'extensions, conflits de remplissage automatique et dépendance d'Android aux Services Google Play - apparaissent dans des systèmes adjacents tels que le remplissage automatique, les permissions, Shields ou l'intégration Wallet. Ils entourent le flux WebAuthn plutôt que de le remplacer.

3. Une clé d'accès créée sur macOS peut-elle être utilisée dans Safari sur un autre appareil Apple ?#

Oui, mais seulement si la clé d'accès est sauvegardée dans le Trousseau iCloud. Sur macOS, Brave utilise la pile WebAuthn de Chromium et peut stocker une nouvelle clé d'accès soit dans l'authentificateur de plateforme Apple, soit dans une autre cible de stockage présentée dans l'invite de création. Une clé d'accès sauvegardée dans le Trousseau iCloud se synchronise via l'identifiant Apple et devient disponible dans Safari, Chrome et d'autres navigateurs compatibles WebAuthn sur les appareils Apple qui partagent cet identifiant Apple.

Une fois que macOS confirme que Brave est autorisé à accéder au Trousseau iCloud, le navigateur peut utiliser les mêmes clés d'accès synchronisées que celles que voit Safari. Cette invite de permission est le moment pratique où la portabilité inter-navigateurs sur les appareils Apple devient réelle plutôt que théorique.

Brave sur macOS peut également participer aux flux d'authentification multi-appareils (CDA). Si l'utilisateur autorise l'accès au Bluetooth, Brave peut découvrir et communiquer avec les appareils à proximité pendant le CDA, ce qui rend l'approbation des clés d'accès par téléphone largement transparente depuis le navigateur de bureau.

Une clé d'accès sauvegardée dans le stockage d'un profil de navigateur ou dans un stockage local uniquement ne devient pas automatiquement disponible dans Safari sur un autre appareil Apple. Cette différence est importante car la synchronisation de l'authentificateur de plateforme au niveau du système d'exploitation et la synchronisation du profil de navigateur suivent des règles différentes. Brave ne fournit pas la synchronisation des clés d'accès du Gestionnaire de mots de passe Google de Chrome, donc seul le chemin du Trousseau iCloud offre une portabilité inter-navigateurs de type Apple sur les appareils Apple.

4. Pourquoi les clés d'accès ne fonctionnent-elles pas de manière fiable sur Android sans les Services Google Play ?#

Le Credential Manager d'Android ne fait pas lui-même partie des Services Google Play. Sur Android 14 et ultérieur, Chromium peut utiliser le chemin du Credential Manager système, tandis que les versions Android plus anciennes s'appuient plus lourdement sur la couche FIDO2 soutenue par les Services Google Play. Dans la pratique, Brave hérite toujours de l'échec documenté dans le problème #45415 : sur GrapheneOS, CalyxOS, /e/OS et d'autres versions Android dé-Googleisées sans le chemin requis des Services Play, l'enregistrement et l'authentification par clé d'accès peuvent expirer (time out). En avril 2026, cela restait une lacune de compatibilité ouverte pour les utilisateurs Android soucieux de leur vie privée.

Ce comportement est documenté dans le problème brave/brave-browser #45415, ouvert en avril 2025 et toujours ouvert un an plus tard. La documentation du Credential Manager de Google distingue l'API du Credential Manager de la dépendance d'authentification optionnelle des Services Play utilisée sur les anciennes versions d'Android, et le guide Android plus large note qu'Android 14+ peut fonctionner avec des gestionnaires de mots de passe activés. Le fil de discussion note également que le même mode de défaillance affecte plus largement les navigateurs basés sur Chromium, tandis que les navigateurs basés sur Firefox ne sont pas affectés de la même manière. Le rapporteur initial a souligné que GrapheneOS a corrigé la dépendance dans son propre fork Chromium, Vanadium, donc une correction en aval semble techniquement possible - elle n'a tout simplement pas eu lieu.

Plusieurs utilisateurs ont confirmé indépendamment le comportement dans ce fil de discussion. Un test particulièrement propre en décembre 2025 a utilisé le même appareil avec deux profils : les clés d'accès ne fonctionnaient dans Brave que sur le profil avec les Services Play activés, tandis que Vanadium et Cromite fonctionnaient sur les deux. En avril 2026, aucun mainteneur de Brave n'avait répondu dans le fil de discussion. Pour le public Android de Brave soucieux de la confidentialité - qui comprend un nombre disproportionné d'utilisateurs dé-Googleisés - cela laisse une lacune très visible. Firefox sur Android utilise sa propre pile WebAuthn et ne dépend pas des Services Play de la même manière. Aujourd'hui, la solution de contournement pratique consiste à utiliser Firefox pour les flux de clés d'accès sur Android sans les Services Play, ou à se rabattre sur une clé de sécurité matérielle avec un client compatible. Pour le paysage plus large des défaillances sur Android, consultez Erreurs de clés d'accès dans les applications natives. Pour les spécificités des Services Google Play et du Credential Manager, consultez Codes d'erreur de clé d'accès Android & Google Play Services.

5. Pourquoi les invites de clés d'accès Windows Hello apparaissent-elles même lorsque je les désactive ?#

Désactiver le paramètre « proposer d'enregistrer les clés d'accès » de Brave n'empêche pas Windows Hello d'apparaître pendant les flux WebAuthn. Une fois qu'un site appelle WebAuthn et que Windows Hello est configuré, Windows annonce Hello comme un authentificateur de plateforme et Brave n'expose aucun contrôle destiné à l'utilisateur qui le bloque. En janvier 2026, la suppression de Windows Hello restait non résolue pour les utilisateurs qui voulaient Hello pour déverrouiller l'appareil mais pas pour les clés d'accès.

Le problème #51858, ouvert en janvier 2026, et le plus long fil de discussion communautaire 646042 décrivent la même chose. Le rapporteur original a essayé des modifications du registre, des stratégies de groupe, des bascules d'indicateurs et des installations propres - rien de tout cela n'a changé le comportement.

La raison technique décrite dans le fil de discussion 646042 est simple : les paramètres du gestionnaire de mots de passe du navigateur contrôlent le propre comportement de remplissage automatique du navigateur, pas la limite WebAuthn entre la page et le système d'exploitation. Windows expose Hello de manière indépendante, et la discussion n'identifie pas de configuration documentée et prise en charge qui préserve Windows Hello pour le déverrouillage de l'appareil tout en le bloquant totalement en tant qu'authentificateur de plateforme WebAuthn.

Aujourd'hui, le seul moyen fiable de supprimer ces invites est de désactiver entièrement l'inscription à Windows Hello, ce qui entre manifestement en conflit avec la façon dont la plupart des gens veulent déverrouiller leur appareil. Edge se comporte différemment car il est plus étroitement intégré à la couche de gestion des identifiants de Windows et expose des contrôles que les forks de Chromium n'ont pas actuellement. Pour un aperçu plus large du comportement des clés d'accès sur Windows, consultez Clés d'accès sur Windows 11.

6. Faut-il stocker les clés d'accès nativement ou dans votre gestionnaire de mots de passe ?#

Le stockage natif des clés d'accès est l'option la plus simple au sein d'un seul écosystème, tandis que les extensions de gestionnaires de mots de passe restent la seule couche de synchronisation multiplateforme largement exploitable. Le Trousseau iCloud fonctionne bien sur les appareils Apple, Windows Hello fonctionne sur Windows et les coffres-forts basés sur des extensions tels que 1Password ou Bitwarden restent la seule option réaliste pour les utilisateurs qui souhaitent que les clés d'accès soient disponibles nativement de manière cohérente sur Windows, macOS, Linux et Android. L'authentification multi-appareils (CDA, ou transport hybride via un code QR et Bluetooth) peut toujours faire le lien entre les appareils au moment de la connexion, mais elle ne synchronise pas l'identifiant lui-même et ne le rend pas disponible localement partout par défaut. Le compromis est la fiabilité : les flux natifs sont plus simples, les flux d'extensions sont plus portables et la CDA est mieux comprise comme un chemin de secours plutôt que comme une stratégie de stockage.

La décision se résume principalement à trois choses : combien de plateformes vous utilisez, à quel point vous faites confiance aux flux d'extensions et où vous gardez déjà vos identifiants. Si vous restez principalement dans un seul écosystème OS - tout Apple, ou tout Windows - la voie de l'authentificateur de plateforme natif est l'option la plus propre. Dans cette configuration, Brave se comporte un peu comme Chrome ou Safari. Si vous avez besoin que les clés d'accès vous suivent sur Windows, macOS, Linux et Android, une extension de gestionnaire de mots de passe tierce telle que 1Password, Bitwarden, Dashlane ou Proton Pass reste la seule couche de synchronisation globalement viable.

La complication est que, depuis avril 2024, des rapports continuent d'affluer selon lesquels l'interface utilisateur native des clés d'accès pirate par intermittence les flux pilotés par des extensions. Les utilisateurs dans le problème #37762 décrivent des boîtes de dialogue d'authentification de l'OS apparaissant alors que Bitwarden ou 1Password devrait posséder l'identifiant. En mars 2026, l'ancienne solution de contournement - désactiver brave://flags/#web-authentication-new-passkey-ui - n'était plus disponible car l'indicateur avait été supprimé dans la version 146.

En pratique, le modèle adopté par de nombreux utilisateurs soucieux de la confidentialité en 2026 est hybride : utiliser l'authentificateur de plateforme OS pour les connexions quotidiennes au sein d'un écosystème, utiliser une extension de gestionnaire de mots de passe là où la portabilité multiplateforme compte et garder une clé de sécurité matérielle à portée de main pour les comptes de grande valeur.

7. Quels sont les points de friction liés aux clés d'accès signalés par les utilisateurs en 2026 ?#

Les problèmes de clés d'accès ouverts dans Brave en 2026 se regroupent autour de trois thèmes récurrents : l'interception par les extensions, les défaillances d'Android sur les appareils dé-Googleisés et les problèmes de clé de sécurité sur ordinateur de bureau. En avril 2026, le dépôt plus large montrait toujours 24 problèmes ouverts correspondant à webauthn ou passkey, ce qui suggère que la friction est concentrée, et non aléatoire.

Le groupe le plus actif est l'interception par les extensions, où l'interface utilisateur native des clés d'accès peut supplanter les invites de 1Password, Bitwarden ou Dashlane. La compatibilité Android sans les Services Google Play est le deuxième problème récurrent, et la détection des clés de sécurité sur ordinateur de bureau est le troisième. Les fils de discussion les plus souvent référencés ici sont #37762, #50561, #45415, #15650, #43043, #34441, #33237 et #51858. Les fils actifs pointent dans la même direction sans avoir besoin de nombreuses citations directes.

Plusieurs de ces problèmes ont reçu de nouveaux commentaires au cours des 90 derniers jours, ce qui en fait des régressions actives plutôt que des curiosités historiques. Pour les développeurs qui construisent des flux de clés d'accès, la conclusion est claire : testez explicitement les flux pilotés par des extensions dans Brave et proposez des solutions de repli judicieuses lorsque les appels WebAuthn échouent. Pour les utilisateurs, la leçon est tout aussi pratique : gardez une clé de sécurité matérielle ou un autre facteur de récupération configuré sur vos comptes importants.

8. Conclusion#

L'histoire des clés d'accès dans Brave est propre au niveau du code et désordonnée au niveau de l'expérience utilisateur. Le chemin WebAuthn est en fait celui de Chromium, avec un seul remplacement de chaîne confirmant à quel point l'implémentation reste proche du code en amont. Sur les plateformes Apple, la portabilité des clés d'accès fonctionne exactement comme les utilisateurs s'y attendent, car le Trousseau iCloud détient l'identifiant. La véritable friction se situe ailleurs : l'interception par les extensions (#37762), la suppression de Windows Hello (#51858) et la dépendance d'Android aux Services Google Play (#45415). Jusqu'à ce que ces problèmes soient résolus, les développeurs devraient tester Brave séparément au lieu de supposer une parité avec Chrome, et les utilisateurs devraient conserver une solution de secours robuste - idéalement une clé de sécurité matérielle - pour leurs comptes importants.

9. À propos de Corbado#

Corbado construit une infrastructure de clés d'accès pour la connexion des consommateurs et fournit une plateforme d'intelligence des clés d'accès pour les équipes qui doivent exploiter des clés d'accès et des systèmes d'authentification à grande échelle. Nous publions des analyses techniques sur le comportement de WebAuthn et des clés d'accès sur les navigateurs et les systèmes d'exploitation en nous basant sur des déploiements réels, une inspection directe du code source et une lecture attentive des spécifications sous-jacentes. Les questions ou corrections sont toujours les bienvenues.

10. Foire aux questions#

10.1 Une clé d'accès créée dans Brave sur macOS peut-elle être utilisée dans Safari sur un autre appareil Apple ?#

Oui, mais seulement si Brave sauvegarde la clé d'accès dans le Trousseau iCloud. Sur macOS, Brave utilise la pile WebAuthn de Chromium et peut stocker une nouvelle clé d'accès dans le Trousseau iCloud ou dans une autre cible de stockage affichée dans l'invite de création. Une clé d'accès sauvegardée dans le Trousseau iCloud se synchronise via l'identifiant Apple et devient disponible dans Safari, Chrome et d'autres navigateurs sur les appareils Apple qui partagent cet identifiant Apple. Une clé d'accès sauvegardée dans le stockage d'un profil de navigateur ou dans un stockage local uniquement ne devient pas automatiquement disponible dans Safari sur un autre appareil Apple.

10.2 Pourquoi les clés d'accès échouent-elles dans Brave sur Android sans les Services Google Play ?#

Brave sur Android peut échouer sans les Services Google Play, mais la raison est plus spécifique que « Le Credential Manager fait partie des Services Play ». Le Credential Manager d'Android est un système et une API Jetpack, tandis que les versions Android plus anciennes s'appuient davantage sur la couche FIDO2 soutenue par les Services Google Play. En pratique, Brave hérite toujours de l'échec documenté dans le problème brave/brave-browser #45415 : sur GrapheneOS, CalyxOS ou d'autres versions d'Android dé-Googleisées sans le chemin requis des Services Play, la boîte de dialogue de clé d'accès ne s'ouvre jamais et l'enregistrement ou l'authentification expirent (time out).

Pour le paysage plus large des défaillances sur Android, consultez Erreurs de clés d'accès dans les applications natives. Pour les spécificités des Services Google Play et du Credential Manager, consultez Codes d'erreur de clé d'accès Android & Google Play Services.

10.3 Brave synchronise-t-il les clés d'accès entre les appareils comme le fait Chrome ?#

Non. Brave ne fournit pas d'équivalent à la synchronisation des clés d'accès du profil de navigateur de Chrome via le Gestionnaire de mots de passe Google. Les clés d'accès créées dans Brave sont stockées dans l'authentificateur de plateforme du système d'exploitation sous-jacent - Trousseau iCloud sur Apple, Windows Hello sur Windows et Credential Manager Android sur Android - et se synchronisent uniquement via ce compte de système d'exploitation. Si vous souhaitez une synchronisation cohérente entre les appareils, vous dépendez du fournisseur du système d'exploitation ou d'une extension de gestionnaire de mots de passe tierce.

10.4 Pourquoi Brave demande-t-il des clés d'accès Windows Hello même lorsque je désactive les options de clés d'accès dans les paramètres ?#

La bascule brave://password-manager/settings de Brave contrôle uniquement si Brave propose de sauvegarder les clés d'accès lui-même. Elle n'empêche pas Windows d'annoncer Windows Hello comme un authentificateur de plateforme WebAuthn à la page. Le site appelle WebAuthn, Windows présente Hello et Brave n'a pas de commutateur intégré au navigateur pour supprimer la boîte de dialogue de l'OS. Le comportement est suivi dans le problème brave/brave-browser #51858.

10.5 Dois-je stocker les clés d'accès dans le flux natif de Brave ou dans mon gestionnaire de mots de passe ?#

Utilisez le flux OS natif de Brave (Trousseau iCloud ou le Gestionnaire de mots de passe Google via la plateforme) si vous restez dans un seul écosystème et que vous souhaitez le moins de pièces mobiles possible. Utilisez une extension de gestionnaire de mots de passe tierce telle que 1Password ou Bitwarden si vous avez besoin que les clés d'accès vous suivent de manière cohérente sur Windows, macOS, Linux et Android, ou si vous y gardez déjà vos secrets. Depuis 2024, l'interface utilisateur native de Brave a intercepté à plusieurs reprises les flux de clés d'accès d'extensions, il vaut donc la peine de vérifier que l'extension possède toujours l'invite.

10.6 Combien de problèmes ouverts sur les clés d'accès et WebAuthn le dépôt brave/brave-browser compte-il actuellement concernant le comportement des clés d'accès de Brave ?#

En avril 2026, brave/brave-browser avait 24 problèmes ouverts correspondant aux recherches passkey ou WebAuthn. Les problèmes ouverts étiquetés avec « passkey » sont passés d'environ 2 par an en 2022-2023 à 6 ouverts en 2025. Pour Brave, les thèmes dominants sont l'interception par les extensions sur ordinateur de bureau, la suppression de Windows Hello et la dépendance aux Services Google Play d'Android.

À propos de Corbado

Corbado est la Authentication Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →