Test des passkeys dans les applications natives : Le guide des gestionnaires de mots de passe tiers

Avec la sortie d'iOS 17 et d'Android 14, le paysage des passkeys pour les applications mobiles natives a radicalement changé. Pour la première fois, les gestionnaires de mots de passe tiers peuvent servir de fournisseurs de passkeys, brisant ainsi le monopole du Trousseau iCloud et du Gestionnaire de mots de passe de Google. Cela permet aux utilisateurs d'utiliser leurs propres solutions de confiance comme 1Password, Bitwarden ou Dashlane dans les flux d'authentification des applications natives. Bien que ce soit une avancée majeure pour le choix des utilisateurs, cela introduit une complexité non négligeable pour les développeurs. L'implémentation de vos passkeys peut se comporter différemment selon les gestionnaires de mots de passe dans les applications mobiles natives. Il est donc essentiel pour toute équipe de tester correctement les passkeys des applications natives avec les gestionnaires de mots de passe tiers.

Ce guide complet partage notre approche éprouvée pour le test des passkeys dans les applications natives avec des gestionnaires de mots de passe tiers. Bien que l'écosystème des passkeys ait considérablement mûri en 2025, la mise en œuvre concrète nécessite encore 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 de manière transparente avec les gestionnaires de mots de passe préférés des utilisateurs.

L'écosystème des gestionnaires de mots de passe a évolué au-delà des solutions natives des plateformes. Les utilisateurs choisissent activement des gestionnaires de mots de passe tiers comme 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 s'adapter à cette diversité sans forcer les utilisateurs à changer leur solution de gestion de mots de passe de confiance.

D'après les données que nous mesurons sur les pages de Corbado, nous constatons que seulement 5 à 10 % des utilisateurs grand public s'appuient sur des gestionnaires de mots de passe tiers. Même si ce chiffre peut paraître faible, il aura un impact énorme sur la perception de votre implémentation de passkeys et sur le nombre de tickets de support si vous travaillez dans un environnement à grande échelle. Nous avons observé 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 des variations subtiles dans l'expérience utilisateur, voire des bugs.

Les applications natives iOS et Android proposent différentes manières d'utiliser les passkeys. Sur Android, on trouve des superpositions (overlays) pour les passkeys et des saisies manuelles dans des champs de texte qui déclenchent la cérémonie de passkey (pour les applications web, Android prend également en charge la Conditional UI). iOS présente son propre ensemble de superpositions pour les passkeys ainsi que la Conditional UI et des saisies manuelles dans des champs de texte. De plus, il existe d'autres cas particuliers à vérifier. En résumé, votre application native doit gérer avec fluidité :

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

Une configuration correcte des flags détermine si les passkeys fonctionnent comme prévu sur tous les appareils et plateformes. Les valeurs critiques incluent :

• Relying Party ID (rpID) : Doit correspondre exactement entre les implémentations web et natives et représente le domaine auquel le passkey est lié
• User verification : Détermine que l'utilisateur doit fournir son authentification locale
• Resident key/discoverable credentials : Permet une authentification sans nom d'utilisateur (autorise la Conditional UI)
• Backup eligibility (BE) et backup state (BS) : Permettent la synchronisation des passkeys entre les appareils

Des flags 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 des passkeys disponibles sur un appareil mais non synchronisés sur d'autres (même si le même gestionnaire de mots de passe tiers est disponible sur les deux appareils). L'une de nos découvertes lors des tests a été que certains gestionnaires de mots de passe tiers définissaient incorrectement les flags BE/BS, ce qui était à l'origine d'une grande partie des problèmes de passkeys.

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 fermée, votre application doit préserver son état, gérer les callbacks et reprendre correctement. C'est particulièrement critique sur Android, où la configuration launchMode peut provoquer des comportements inattendus.

Par exemple, nous avons constaté que définir MainActivity sur launchMode="singleInstance" créait des problèmes. Sur certaines versions d'Android et personnalisations des fabricants (OEM), ce mode fait en sorte que l'interface du Credential Manager pour les passkeys s'ouvre comme une tâche distincte. Non seulement cela ajoute une entrée d'application supplémentaire et déroutante à l'écran "Récents", mais cela peut également bloquer l'application si elle est mise en arrière-plan pendant que la boîte de dialogue du passkey est ouverte.

La solution recommandée est de changer la configuration pour launchMode="singleTask". Cela empêche le Credential Manager de générer une tâche séparée, assurant un cycle de vie plus prévisible entre les différents fabricants (Samsung, Google, Vivo, etc.) et réduisant le risque de bugs spécifiques au vendeur. Cela fournit une base plus stable pour tester la navigation, les superpositions et les deeplinks.

Nous avons observé que de tels problèmes de cycle de vie se font souvent passer pour des "bugs du gestionnaire de mots de passe" alors qu'il s'agit en réalité de problèmes au niveau de l'application. Une instrumentation et des tests appropriés sur différents fournisseurs aident à identifier ces schémas à un stade précoce.

Concentrez vos tests de passkeys pour application native 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 ex., Samsung Pass pour les appareils Samsung)
• Solutions d'entreprise si vous ciblez des utilisateurs professionnels
• Solutions par défaut des plateformes (Google Password Manager, Trousseau iCloud) 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 en UE/USA/Royaume-Uni/AUS/NZ.

Avant de commencer chaque session de test, assurez-vous d'avoir un environnement propre et reproductible :

1. État des identifiants propre :

• Supprimez tous les identifiants existants pour votre RP ID
• Videz 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. Stabiliser l'environnement de test :

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

Chaque test valide des aspects spécifiques de la fonctionnalité des passkeys. Documentez systématiquement les résultats avec un statut de réussite/échec et des notes détaillées pour toute anomalie.

Valider la gestion correcte de l'annulation

✓ La feuille du gestionnaire de mots de passe s'ouvre correctement ✓ L'utilisateur annule sans créer de passkey ✓ L'application retourne à l'écran de connexion ✓ Aucun identifiant orphelin dans le gestionnaire de mots de passe ✓ L'interface affiche des options de nouvelle tentative appropriées

Vérifier la création de passkey 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 boucle

Tester les scénarios d'authentification standards

✓ L'interface de superposition de passkey apparaît ou l'utilisateur fournit son nom d'utilisateur dans le scénario avec champ de texte ✓ L'analyse biométrique et une seule invite biométrique mènent à une authentification réussie ✓ Pas de boucles de sélection ou de réapparitions de la feuille ✓ La session reste stable après l'authentification

Valider la gestion des passkeys dans l'application

✓ RP ID, découvrabilité et flags 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 bons libellés

Tester la gestion du cycle de vie des identifiants

✓ Supprimer le passkey dans les paramètres ✓ La connexion par passkey n'est pas possible ✓ Une option de secours appropriée est proposée

Valider la portabilité de l'application vers le web

✓ Le navigateur reconnaît les passkeys créés par l'application ✓ La feuille de sélection montre la bonne association RP ✓ L'authentification se termine sans détour par QR/CDA

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 du premier coup ✓ Pas de recours forcé au mot de passe

Vérifier la synchronisation des passkeys de l'application native vers le navigateur de bureau

✓ Le passkey créé par l'application se synchronise avec le gestionnaire de mots de passe de bureau ✓ Le passkey synchronisé fonctionne de manière transparente dans le navigateur de bureau ✓ Aucun flux de code QR / inter-appareils n'est déclenché ✓ L'authentification se termine sans boucles ni erreurs

Vérifier la synchronisation des passkeys du navigateur de bureau vers l'application native

✓ Le passkey créé sur l'ordinateur se synchronise avec le gestionnaire de mots de passe mobile ✓ L'application native affiche correctement le passkey synchronisé ✓ L'authentification réussit sans recours au mot de passe ✓ Les logs lient l'assertion au bon credential ID

Valider les scénarios où le téléphone sert de clé de sécurité

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

Nos tests approfondis ont révélé plusieurs schémas récurrents qui affectent l'intégration des passkeys des gestionnaires de mots de passe tiers :

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

Solution : Implémentez une logique de nouvelle tentative avec un mécanisme d'attente exponentielle (exponential backoff). Proposez des options d'actualisation manuelle pour les utilisateurs rencontrant des délais de synchronisation.

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

Solution : Maintenez une matrice de compatibilité et ajustez les flux en fonction de la version de l'OS détectée. Envisagez des exigences de version minimale pour une expérience optimale.

La mise en œuvre réussie du support des passkeys 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 essais en conditions réelles, fournit une base solide pour valider votre intégration des passkeys.

Points clés à retenir pour le déploiement en production :

1. Testez systématiquement : Utilisez notre plan de test comme base, 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, pas seulement ceux par défaut de la plateforme
3. Surveillez en continu : Implémentez une journalisation complète pour détecter les cas limites en production
4. Documentez rigoureusement : Conservez des enregistrements clairs des comportements spécifiques aux fournisseurs et des solutions de contournement

L'écosystème des passkeys 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 mûrit.

Nous continuerons à mettre à jour nos SDK et notre méthodologie de test à mesure que de nouveaux schémas émergeront. L'investissement dans des tests complets des gestionnaires de mots de passe tiers porte ses fruits en réduisant la charge de support et en améliorant la satisfaction des utilisateurs. Après tout, l'authentification doit simplement fonctionner, quel que soit le gestionnaire de mots de passe que vos utilisateurs choisissent.