Test des gestionnaires de mots de passe tiers pour les clés d'accès d'applications natives

1. Introduction : Les clés d'accès des applications natives rencontrent les gestionnaires de mots de passe tiers#

Avec la sortie d'iOS 17 et d'Android 14, le paysage des clés d'accès pour les applications mobiles natives a fondamentalement changé. Pour la première fois, les gestionnaires de mots de passe tiers peuvent agir en tant que fournisseurs de clés d'accès, brisant ainsi l'emprise exclusive d'Apple Passwords (iCloud Keychain) et de Google Password Manager. Cela permet aux utilisateurs d'apporter leurs propres solutions de confiance telles que 1Password, Bitwarden ou Dashlane dans les flux d'authentification des applications natives. Bien qu'il s'agisse d'une énorme victoire pour le choix de l'utilisateur, cela introduit une complexité significative pour les développeurs. L'implémentation de vos clés d'accès peut se comporter différemment selon les différents gestionnaires de mots de passe dans les applications mobiles natives. Il est donc important pour toute équipe de tester correctement les clés d'accès d'applications natives et les gestionnaires de mots de passe tiers.

Ce guide complet partage notre approche éprouvée pour tester les clés d'accès d'applications natives avec des gestionnaires de mots de passe tiers. Bien que l'écosystème des clés d'accès ait considérablement mûri en 2025, une implémentation dans le monde réel nécessite toujours une validation minutieuse à travers diverses implémentations de gestionnaires de mots de passe. Nous avons condensé notre expérience dans un plan de test pratique qui garantit que votre application native fonctionne parfaitement avec les gestionnaires de mots de passe préférés des utilisateurs.

2. Pourquoi les tests de clés d'accès sont importants en production#

2.1 Les utilisateurs apportent leur propre gestionnaire de mots de passe#

L'écosystème des gestionnaires de mots de passe a évolué au-delà des solutions natives de la plateforme. Les utilisateurs choisissent activement des gestionnaires de mots de passe tiers tels que 1Password, Bitwarden, Dashlane, Proton Pass et NordPass en fonction de leurs besoins spécifiques, tels que la synchronisation multiplateforme, les fonctionnalités d'entreprise ou les préférences de confidentialité. Votre application native iOS / Android doit tenir compte de cette diversité sans obliger les utilisateurs à changer leur solution de gestion des mots de passe de confiance.

D'après les données que nous mesurons sur les pages Corbado, nous constatons que seuls 5 à 10 % des utilisateurs grand public s'appuient sur des gestionnaires de mots de passe tiers. Même si ce chiffre peut sembler faible, il aura un impact énorme sur la perception de votre implémentation de clés d'accès et le nombre de tickets d'assistance si vous travaillez dans un environnement à grande échelle. Nous avons constaté que certains gestionnaires de mots de passe implémentent la spécification WebAuthn de manière légèrement différente, ce qui entraîne de subtiles variations dans l'expérience utilisateur, voire des bogues.

2.2 Différents modèles d'UX dans les applications natives#

Les applications natives iOS et Android offrent différentes façons d'utiliser les clés d'accès. Sur Android, vous rencontrerez des superpositions (overlays) de clés d'accès et des saisies manuelles de champs de texte qui déclenchent une cérémonie de clé d'accès (pour les applications web, Android prend également en charge l'interface utilisateur conditionnelle, Conditional UI). iOS présente son propre ensemble de superpositions de clés d'accès aux côtés de l'interface utilisateur conditionnelle et des saisies manuelles de champs de texte. De plus, il existe d'autres cas particuliers à vérifier. Dans l'ensemble, votre application native doit gérer gracieusement :

• Les connexions par superposition de clés d'accès qui apparaissent immédiatement au chargement de la page
• Les connexions via Conditional UI (iOS uniquement) qui suggèrent automatiquement les clés d'accès disponibles
• Les connexions par champ de texte où l'utilisateur saisit son nom d'utilisateur avant de cliquer sur un bouton
• L'authentification multi-appareils (CDA) pour l'utilisation d'une clé d'accès avec un autre appareil
• Les mécanismes de secours (fallback) lorsque l'utilisation d'une clé d'accès n'est pas disponible

2.3 Les indicateurs WebAuthn exigent de la précision#

Une configuration correcte des indicateurs détermine si les clés d'accès fonctionnent comme prévu sur l'ensemble des appareils et des plateformes. Les valeurs critiques comprennent :

• Relying Party ID (rpID) : Doit correspondre exactement entre les implémentations web et natives et constitue le domaine auquel la clé d'accès est liée
• Vérification de l'utilisateur (User verification) : Détermine que l'utilisateur doit fournir son authentification locale
• Clé résidente/identifiants découvrables (Resident key/discoverable credentials) : Permet une authentification sans nom d'utilisateur (permet l'interface utilisateur conditionnelle)
• Éligibilité à la sauvegarde (Backup eligibility, BE) et état de la sauvegarde (Backup state, BS) : Permet la synchronisation inter-appareils des clés d'accès

Des indicateurs mal configurés ne provoquent pas toujours des échecs immédiats. Cependant, ils peuvent créer des problèmes subtils et des incohérences, comme le fait que les clés d'accès soient disponibles sur un appareil mais non synchronisées sur d'autres (même si le même gestionnaire de mots de passe tiers peut être disponible sur les deux appareils). L'une de nos découvertes lors des tests a été que certains gestionnaires de mots de passe tiers configurent de manière incorrecte les indicateurs BE/BS, ce qui représentait une grande partie des problèmes liés aux clés d'accès.

2.4 Gestion du cycle de vie dans les applications à instance unique#

Les architectures à activité unique (Android) et à scène unique (iOS) nécessitent une gestion méticuleuse du cycle de vie. Lorsqu'une feuille de gestionnaire de mots de passe apparaît puis est rejetée, votre application doit préserver son état, gérer les retours d'appel (callbacks) et reprendre correctement. Ceci est particulièrement critique sur Android, où la configuration launchMode peut provoquer un comportement inattendu.

Par exemple, nous avons découvert que le réglage de MainActivity sur launchMode="singleInstance" posait des problèmes. Sur certaines versions d'Android et personnalisations d'équipementiers, ce mode provoque l'ouverture de l'interface du Passkey Credential Manager en tant que tâche distincte. Non seulement cela ajoute une entrée d'application supplémentaire et déroutante à l'écran "Récentes", mais cela peut également provoquer le blocage de l'application si elle est placée en arrière-plan pendant que la boîte de dialogue de la clé d'accès est ouverte.

Le correctif recommandé consiste à changer la configuration pour launchMode="singleTask". Cela empêche Credential Manager de générer une tâche distincte, ce qui garantit un cycle de vie plus prévisible entre les différents équipementiers (Samsung, Google, Vivo, etc.) et réduit le risque de bogues spécifiques aux fournisseurs. Cela fournit une base plus stable pour tester la navigation, les superpositions et les liens profonds (deeplinks).

Nous avons observé que de tels problèmes de cycle de vie se font souvent passer pour des "bogues du gestionnaire de mots de passe" alors qu'il s'agit en fait de problèmes au niveau de l'application. Une instrumentation appropriée et des tests auprès de différents fournisseurs aident à identifier ces modèles de manière précoce.

3. Configuration de votre environnement de test#

3.1 Gestionnaires de mots de passe cibles#

Concentrez vos tests de clés d'accès d'applications natives sur les gestionnaires de mots de passe tiers les plus largement adoptés :

Cibles principales (couverture essentielle) :

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Cibles secondaires (en fonction de votre base d'utilisateurs) :

• Fournisseurs régionaux (par exemple, Samsung Pass pour les appareils Samsung)
• Solutions d'entreprise si vous ciblez les utilisateurs professionnels
• Valeurs par défaut de la plateforme (Google Password Manager, iCloud Keychain) comme référence

Évitez la tentation de tester tous les gestionnaires de mots de passe disponibles. Concentrez-vous sur les fournisseurs qui représentent 90 % de votre base d'utilisateurs. Nos analyses ont montré que les cinq cibles principales couvraient 85 % des utilisateurs de gestionnaires de mots de passe tiers dans l'UE, aux États-Unis, au Royaume-Uni, en Australie et en Nouvelle-Zélande.

3.2 Liste de contrôle avant le vol#

Avant de commencer chaque série de tests, assurez-vous d'avoir un environnement propre et reproductible :

1. État des identifiants vierge :

• Supprimez tous les identifiants existants pour votre RP ID
• Effacez les caches du navigateur et de l'application
• Déconnectez-vous complètement et reconnectez-vous au gestionnaire de mots de passe
• Forcez la fermeture et relancez l'application cible

2. Stabilisez l'environnement de test :

• Assurez une connectivité réseau stable (pas de VPN pendant les tests)
• Désactivez les animations de l'interface utilisateur si vous automatisez les tests
• Utilisez une orientation de l'appareil constante
• Documentez la version de l'OS, la version de l'application et la version du gestionnaire de mots de passe

4. Le plan de test complet#

Chaque test valide des aspects spécifiques de la fonctionnalité des clés d'accès. Documentez systématiquement les résultats en utilisant le statut de réussite/échec et des notes détaillées pour toute anomalie.

4.1 Tests du flux d'authentification principal#

Test 1 : Annuler la création d'une clé d'accès (après une connexion classique réussie)#

Valider la gestion d'une annulation en douceur

✓ La feuille du gestionnaire de mots de passe s'ouvre correctement
✓ L'utilisateur annule sans créer de clé d'accès
✓ L'application revient à l'écran de connexion ✓ Aucun identifiant orphelin dans le gestionnaire de mots de passe
✓ L'interface utilisateur affiche les options de relance appropriées

Test 2 : Créer une clé d'accès (après une connexion classique réussie)#

Vérifier la création de clé d'accès après le flux d'authentification

✓ L'authentification locale se lance de manière fiable
✓ L'authentification biométrique se termine avec succès
✓ L'identifiant est créé avec le bon RP ID
✓ L'application passe à l'état authentifié sans boucles

Test 3 : S'authentifier avec une clé d'accès existante#

Tester les scénarios d'authentification standard

✓ L'interface utilisateur en superposition des clés d'accès apparaît ou l'utilisateur fournit son nom d'utilisateur dans un scénario de champ de texte ✓ L'analyse biométrique et une simple invite biométrique conduisent à une authentification réussie
✓ Aucune boucle de sélection ou réapparition de la feuille
✓ La session reste stable après l'authentification

Test 4 : Créer une clé d'accès depuis les paramètres#

Valider la gestion des clés d'accès dans l'application

✓ Le RP ID, la capacité de découverte et les indicateurs BE/BS corrects
✓ L'application reste authentifiée après la création
✓ Le gestionnaire de mots de passe se met à jour immédiatement avec les étiquettes correctes

Test 5 : Supprimer la clé d'accès et essayer de se reconnecter#

Tester la gestion du cycle de vie des identifiants

✓ Supprimer la clé d'accès dans les paramètres ✓ La connexion par clé d'accès n'est pas possible
✓ Une option de secours (fallback) appropriée est proposée

4.2 Tests de compatibilité multiplateforme#

Test 6 : Utiliser une clé d'accès créée en natif sur le web (Même appareil)#

Valider la portabilité de l'application vers le web

✓ Le navigateur reconnaît les clés d'accès créées par l'application
✓ La feuille de sélection montre l'association correcte au RP
✓ L'authentification se termine sans détour QR/CDA

Test 7 : Utiliser une clé d'accès créée sur le web dans l'application native#

Tester le partage d'identifiants du web vers l'application

✓ L'application affiche l'identifiant créé sur le web dans la sélection
✓ L'authentification réussit à la première tentative
✓ Pas de solution de repli (fallback) forcée sur le mot de passe

Test 8 : Synchronisation inter-appareils (Mobile vers Bureau)#

Vérifier la synchronisation des clés d'accès de l'application native vers le navigateur de bureau

✓ La clé d'accès créée par l'application se synchronise vers le gestionnaire de mots de passe de bureau ✓ La clé d'accès synchronisée fonctionne parfaitement dans le navigateur de bureau ✓ Aucun code QR / flux inter-appareils n'est déclenché ✓ L'authentification se termine sans boucles ni erreurs

Test 9 : Synchronisation inter-appareils (Bureau vers Mobile)#

Vérifier la synchronisation des clés d'accès du navigateur de bureau vers l'application native

✓ La clé d'accès créée sur le bureau se synchronise avec le gestionnaire de mots de passe mobile ✓ L'application native affiche correctement la clé d'accès synchronisée ✓ L'authentification réussit sans repli sur le mot de passe ✓ Les journaux associent l'assertion à l'ID d'identifiant correct

Test 10 : Mobile comme authentificateur pour le Web#

Valider les scénarios de téléphone en tant que clé de sécurité

✓ Le téléphone propose l'identifiant créé par l'application pour le CDA web
✓ Pas de fausses erreurs "aucune clé d'accès disponible"
✓ La session web se termine après la biométrie mobile

5. Problèmes fréquents et stratégies d'atténuation#

Nos tests approfondis ont révélé plusieurs modèles récurrents qui affectent l'intégration des clés d'accès dans les gestionnaires de mots de passe tiers :

Délais de synchronisation inter-appareils#

Problème : Les identifiants créés sur un appareil peuvent ne pas apparaître immédiatement sur les autres.

Solution : Implémentez une logique de relance avec un intervalle de temporisation exponentiel. Fournissez des options de rafraîchissement manuel pour les utilisateurs confrontés à des délais de synchronisation.

Comportements spécifiques aux versions#

Problème : Le comportement du gestionnaire de mots de passe varie considérablement selon les versions du système d'exploitation, en particulier sous Android 14+ et iOS 17+.

Solution : Maintenez une matrice de compatibilité et ajustez les flux en fonction de la version du système d'exploitation détectée. Envisagez de définir des exigences de version minimale pour une expérience optimale.

6. Conclusion : Intégrer la prise en charge des clés d'accès pour la production#

Mettre en œuvre avec succès la prise en charge des clés d'accès des gestionnaires de mots de passe tiers dans les applications natives nécessite des tests méthodiques et une attention aux détails. Notre plan de test complet, affiné par des tests en conditions réelles, fournit une base solide pour valider votre intégration des clés d'accès.

Principaux points à retenir pour le déploiement en production :

1. Testez systématiquement : Utilisez notre plan de test comme référence, en l'adaptant à vos cas d'utilisation spécifiques
2. Respectez le choix de l'utilisateur : Prenez en charge les gestionnaires de mots de passe que vos utilisateurs préfèrent, et pas seulement ceux proposés par défaut par la plateforme
3. Surveillez en permanence : Implémentez une journalisation complète pour détecter les cas particuliers en production
4. Documentez rigoureusement : Maintenez des registres clairs des comportements et solutions de contournement spécifiques aux fournisseurs

L'écosystème des clés d'accès continue d'évoluer rapidement. Les gestionnaires de mots de passe mettent régulièrement à jour leurs implémentations, les systèmes d'exploitation introduisent de nouvelles fonctionnalités, et la spécification WebAuthn elle-même progresse. En établissant dès maintenant un cadre de test robuste, vous serez prêt à vous adapter à mesure que la technologie gagnera en maturité.

Nous continuerons de mettre à jour nos SDK et notre méthodologie de test au fur et à mesure que de nouveaux modèles apparaîtront. L'investissement dans des tests complets de gestionnaires de mots de passe tiers rapporte des dividendes en réduisant le fardeau de l'assistance et en améliorant la satisfaction des utilisateurs. Après tout, l'authentification devrait simplement fonctionner, peu importe le gestionnaire de mots de passe que vos utilisateurs choisissent.

À propos de Corbado

Corbado est la Passkey 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 →

Foire aux questions#

Quels gestionnaires de mots de passe tiers dois-je privilégier lors des tests de clés d'accès pour les applications natives ?#

Privilégiez 1Password, Bitwarden, Dashlane, Proton Pass et NordPass comme cibles principales. Ces cinq fournisseurs couvrent 85 % des utilisateurs de gestionnaires de mots de passe tiers sur les marchés de l'UE, des États-Unis, du Royaume-Uni, de l'Australie et de la Nouvelle-Zélande, ce qui offre une large couverture sans trop investir dans des fournisseurs marginaux.

Pourquoi les clés d'accès créées dans une application native ne se synchronisent-elles pas entre les appareils lors de l'utilisation d'un gestionnaire de mots de passe tiers ?#

Une configuration incorrecte de l'indicateur d'éligibilité à la sauvegarde (backup eligibility, BE) et de l'état de la sauvegarde (backup state, BS) est une des principales causes des échecs de synchronisation inter-appareils. Certains gestionnaires de mots de passe tiers configurent ces indicateurs de manière incorrecte, de sorte qu'une clé d'accès existe sur un appareil mais ne se synchronise pas avec les autres, même lorsque le même gestionnaire de mots de passe est installé sur les deux.

Comment corriger les bogues d'interface utilisateur d'Android Credential Manager qui apparaissent comme des tâches distinctes dans l'écran Récentes ?#

Le paramétrage de MainActivity sur launchMode singleInstance provoque la génération de l'interface utilisateur de Credential Manager sous forme de tâche distincte, ce qui crée une entrée confuse dans l'écran Récentes et peut potentiellement bloquer l'application lorsqu'elle est mise en arrière-plan. La modification de la configuration vers launchMode singleTask résout ce problème sur tous les équipements d'origine, y compris Samsung, Google et Vivo.

Quels flux d'authentification dois-je tester lors de la validation de la prise en charge d'un gestionnaire de mots de passe tiers dans une application native iOS ou Android ?#

Un plan de test complet couvre 10 scénarios : création de clé d'accès et annulation gracieuse, authentification par superposition et par champ de texte, gestion des identifiants dans l'application, suppression d'identifiants avec option de repli (fallback) et synchronisation bidirectionnelle inter-appareils. Les tests multiplateformes devraient également confirmer que les clés d'accès créées par l'application permettent de s'authentifier dans un navigateur et que celles créées sur le web permettent de s'authentifier dans l'application native.