Passkeys dans les applications natives : Implémentation native ou via WebView

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Note : Les WebViews système et embarquées sont souvent combinées. La WebView système gère la connexion (avec partage automatique des identifiants), puis une WebView embarquée affiche la gestion des passkeys dans les paramètres.

Facteurs de décision clés :

• Connexion basée sur OAuth ? → WebView système (ASWebAuthenticationSession, Chrome Custom Tabs)
• Réutiliser l'authentification web dans une enveloppe native ? → WebView embarquée (WKWebView, WebView Android avec WebKit 1.12.1+)
• Développer une application native-first ? → Implémentation native (AuthenticationServices d'Apple, Credential Manager de Google)

Les plateformes mobiles modernes offrent trois approches distinctes pour intégrer les passkeys dans votre application native. Chacune présente des compromis différents en termes d'expérience utilisateur, de complexité technique et de compatibilité OAuth :

1. Implémentation native : Intégrer les flux de passkeys directement dans votre application à l'aide des API de la plateforme (AuthenticationServices sur iOS, Credential Manager sur Android). Elle offre la meilleure expérience utilisateur avec une authentification biométrique fluide, mais demande un effort de développement moyen à élevé.

2. WebView système : Utiliser le composant de navigateur de la plateforme (ASWebAuthenticationSession / SFSafariViewController sur iOS, Chrome Custom Tabs sur Android) pour gérer l'authentification. C'est une excellente solution pour les flux de connexion basés sur OAuth, et elle partage les identifiants avec le navigateur système.

3. WebView embarquée : Intégrer une vue web personnalisable (WKWebView sur iOS, WebView sur Android) dans votre application pour réutiliser l'authentification web avec une structure d'application native. Cela donne une apparence native sans barre d'URL et un contrôle total sur l'interface de la vue web. Cette approche nécessite une configuration supplémentaire, incluant des permissions et des droits (entitlements) sur iOS, ainsi que la configuration de la WebView avec AndroidX WebKit 1.12.1+ sur Android pour activer la fonctionnalité des passkeys.

Le bon choix dépend de l'architecture d'authentification de votre application, de l'utilisation de fournisseurs OAuth, du niveau de contrôle souhaité sur l'interface utilisateur et de si vous développez une application native-first ou réutilisez des composants web.

Une implémentation native des passkeys offre l'expérience utilisateur optimale, avec des flux d'authentification intégrés directement dans l'interface de votre application à l'aide d'API spécifiques à la plateforme. Les utilisateurs bénéficient de boîtes de dialogue natives, d'une vérification biométrique fluide et des temps de connexion les plus rapides possibles.

Quand choisir l'implémentation native :

• Vous construisez une nouvelle application native ou refondez l'authentification avec des écrans natifs.
• Vous visez la meilleure expérience utilisateur possible avec une authentification instantanée et silencieuse.
• Invites de passkey automatiques au lancement de l'app : Les implémentations natives peuvent utiliser preferImmediatelyAvailableCredentials pour afficher automatiquement une superposition de passkeys si des passkeys sont disponibles, offrant l'expérience de connexion la plus rapide sans avoir à saisir un identifiant.
• Vous avez besoin d'un contrôle total sur l'interface et le flux d'authentification.
• Vous êtes prêt à investir dans une implémentation spécifique à la plateforme (Swift pour iOS, Kotlin pour Android).

Avantage clé : preferImmediatelyAvailableCredentials()

Les implémentations natives peuvent tirer parti de preferImmediatelyAvailableCredentials() pour créer une superposition de passkeys automatique qui apparaît dès le lancement de l'application lorsque des passkeys sont disponibles. Ce flux sans nom d'utilisateur offre l'expérience de connexion la plus rapide possible : les utilisateurs voient leurs passkeys instantanément sans avoir à saisir un identifiant au préalable. Cette fonctionnalité est exclusive aux implémentations natives et n'est pas disponible dans les variantes WebView.

Bien que les implémentations WebView puissent utiliser la Conditional UI (suggestions de passkey dans les champs de saisie), la superposition automatique native offre une meilleure UX avec des taux d'utilisation de passkeys plus élevés, car l'authentification commence dès le lancement de l'application.

Aperçu des exigences techniques :

L'intégration native des passkeys nécessite une confiance cryptographique entre votre application et votre domaine web. Sans cela, le système d'exploitation rejettera toutes les opérations WebAuthn. Exigences clés :

1. Fichiers d'association application-domaine hébergés à /.well-known/.
2. ID de partie de confiance (Relying Party ID) correct correspondant à votre domaine web.
3. Capacités spécifiques à la plateforme (détaillées dans la section 4).

L'avantage majeur : les passkeys créées sur votre site web fonctionnent de manière transparente dans votre application, et vice-versa.

L'implémentation native des passkeys sur iOS passe par le framework AuthenticationServices d'Apple, qui fournit une API pour les opérations WebAuthn :

Composants clés :

• ASAuthorizationController : Gère le flux d'authentification.
• ASAuthorizationPlatformPublicKeyCredentialProvider : Crée les requêtes de passkeys.
• Trois modes d'interface distincts pour gérer les connexions par passkey :
  • Connexion par champ de texte : Champ de nom d'utilisateur traditionnel avec la connexion par passkey qui démarre à la soumission du bouton.
  • Superposition modale de passkeys : Boîte de dialogue du système d'exploitation listant les passkeys disponibles.
  • Conditional UI : Suggestions de passkeys dans la barre QuickType au-dessus du clavier.

Conseils de développement

• Mise en cache AASA : Apple met en cache le fichier AASA de manière agressive (jusqu'à 24 heures), ce qui peut compliquer les tests. Solution : activez le mode développeur sur votre appareil de test et ajoutez ?mode=developer à l'URL de votre AASA pour forcer une nouvelle récupération.
• Tests de performance : Testez avec des comptes iCloud contenant des centaines d'identifiants pour observer la latence en conditions réelles. La superposition système peut présenter un léger retard avec de nombreux passkeys stockés.

L'implémentation native des passkeys sur Android utilise l'API Credential Manager (ou l'ancienne API FIDO2 pour la rétrocompatibilité) :

Composants clés :

• CredentialManager : API centrale pour toutes les opérations sur les identifiants.
• CreatePublicKeyCredentialRequest : Pour l'enregistrement des passkeys.
• GetCredentialRequest : Pour l'authentification par passkey.
• Deux modes d'interface principaux :
  • Connexion par champ de texte : Champ de nom d'utilisateur traditionnel avec la connexion par passkey qui démarre à la soumission du bouton.
  • Superposition modale de passkeys : Boîte de dialogue du système d'exploitation listant les passkeys disponibles.

Note : Android ne dispose pas actuellement des suggestions de clavier Conditional UI d'iOS dans les applications natives (bien que la Conditional UI fonctionne dans les applications web).

L'implémentation native des passkeys présente des défis importants et des leçons à tirer. L'intégration au niveau du système d'exploitation peut révéler des problèmes sur différents appareils et versions d'OS.

1. Par exemple, notre équipe a rencontré des problèmes comme la mise en cache agressive par Apple du fichier apple-app-site-association (utilisé pour lier les identifiants entre l'app et le web) et des différences subtiles dans les invites biométriques de certains fabricants Android.
2. De plus, il faut considérer que dans certains scénarios d'entreprise, les appareils gérés peuvent avoir la synchronisation des passkeys désactivée par une politique. Dans les environnements d'entreprise où la synchronisation du Trousseau iCloud ou du Gestionnaire de mots de passe Google est désactivée, les passkeys deviennent liés à l'appareil et ne se synchronisent pas – un scénario important à prévoir (par exemple, s'assurer que les utilisateurs peuvent toujours se connecter s'ils changent de téléphone).
3. De plus, les applications de gestionnaires de mots de passe tierces peuvent influencer le flux. Par exemple, si un utilisateur a un gestionnaire de mots de passe comme 1Password défini comme fournisseur d'identifiants actif, il interceptera souvent la création et le stockage des passkeys, prenant la priorité sur le gestionnaire d'identifiants natif de la plateforme.

Bien que vous puissiez implémenter les passkeys en utilisant les API brutes de la plateforme, des SDK spécialisés accélèrent considérablement le développement en gérant la complexité de WebAuthn, les cas limites et en fournissant une télémétrie intégrée. Les SDK offrent également des interfaces simulables (mockables) pour les tests unitaires (crucial, car on ne peut pas tester la biométrie dans les simulateurs).

Recommandation : Pour les implémentations natives, nous recommandons d'utiliser les SDK de Corbado (SDK Passkey iOS en Swift, SDK Passkey Android en Kotlin) qui gèrent les nombreux cas limites découverts lors de déploiements en production, et fournissent une télémétrie et des tests supplémentaires.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Des passkeys que des millions de personnes adoptent, rapidement. Démarrez avec la plateforme d'adoption de Corbado.

Démarrer l'essai gratuit

Les WebViews système utilisent le composant de navigateur natif de la plateforme pour gérer l'authentification au sein de votre application. Contrairement aux implémentations entièrement natives, les WebViews système affichent le contenu web en utilisant le véritable navigateur système (Safari sur iOS, Chrome sur Android), conservant ainsi les cookies partagés, les identifiants enregistrés et les indicateurs de sécurité familiers du navigateur.

Quand choisir la WebView système :

• Votre application utilise une connexion basée sur OAuth : La WebView système est l'approche recommandée pour les flux OAuth2/OIDC, offrant une authentification sécurisée.
• Vous avez une authentification web existante que vous souhaitez réutiliser dans des applications mobiles.
• Vous devez prendre en charge plusieurs méthodes d'authentification (mots de passe, connexion sociale, passkeys) sans tout reconstruire nativement.
• Vous voulez maintenir une seule base de code d'authentification pour le web et le mobile.

Avantages clés :

• Compatibilité OAuth : Conçue spécialement pour les flux d'authentification OAuth/OIDC.
• Indicateurs de sécurité : Les utilisateurs voient l'URL réelle et les certificats SSL, ce qui renforce la confiance.
• Faible effort d'implémentation : Peu de code natif requis.
• UX cohérente : Interface de navigateur familière à laquelle les utilisateurs font déjà confiance.

Composants de la plateforme :

• iOS : ASWebAuthenticationSession (recommandé pour les flux d'authentification) ou SFSafariViewController (navigation générale).
• Android : Chrome Custom Tabs (CCT).

De grandes entreprises comme Google et GitHub ont adopté cette approche pour ajouter la connexion par passkey à leurs applications mobiles via des superpositions WebView sur les pages d'authentification web existantes. Cela fonctionne bien lorsque la refonte complète de l'authentification native n'est pas immédiatement réalisable.

iOS fournit deux principaux composants de WebView système pour l'authentification :

ASWebAuthenticationSession (Recommandé pour l'authentification) :

• Conçu spécialement pour les flux OAuth/OIDC et de connexion sécurisée.
• Demande automatiquement à l'utilisateur que l'application souhaite s'authentifier.
• Partage les cookies et les identifiants avec Safari.
• Prend en charge les passkeys via le Trousseau iCloud.

SFSafariViewController (Navigation générale) :

• Expérience Safari complète au sein de l'application.
• Affiche la barre d'URL et les indicateurs de sécurité.
• Ne partage pas les cookies de Safari sur iOS 11+ ; utilisez ASWebAuthenticationSession lorsque le partage de session Safari est requis.
• Moins personnalisable mais plus digne de confiance pour les utilisateurs.

Si votre application utilise une connexion basée sur OAuth, ASWebAuthenticationSession est le choix recommandé car il est spécifiquement conçu pour les scénarios d'authentification et offre le meilleur équilibre entre sécurité et expérience utilisateur.

Les Chrome Custom Tabs (CCT) offrent une expérience d'authentification optimisée par Chrome au sein de votre application :

Fonctionnalités clés :

• Partage les cookies et les identifiants avec le navigateur Chrome.
• Affiche l'URL et les indicateurs de sécurité.
• Permet de personnaliser la couleur de la barre d'outils et le branding.
• Préchauffage pour des temps de chargement plus rapides.

Intégration OAuth : Les Chrome Custom Tabs sont l'équivalent Android de l'ASWebAuthenticationSession d'iOS, offrant un excellent support OAuth tout en conservant l'accès aux passkeys stockés.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Les WebViews embarquées offrent un contrôle total sur le rendu du contenu web au sein de votre application, permettant une manipulation directe des cookies, des sessions et de la navigation sans barre d'URL. Cependant, ce contrôle s'accompagne d'exigences techniques supplémentaires pour activer la fonctionnalité des passkeys.

Quand choisir la WebView embarquée :

• Expérience de type natif : Votre application intègre déjà l'authentification dans une vue web personnalisée pour maintenir une apparence native, et vous souhaitez conserver cette expérience utilisateur cohérente.
• Besoin de contrôle sur la session/les cookies : Votre application nécessite une manipulation directe des jetons d'authentification et de l'état de la session après la fin de l'authentification OAuth.
• Flux d'authentification existant où l'authentification par WebView système renvoie un code d'authentification mais pas de session dans des contextes embarqués.
• Doit maintenir un état authentifié sur plusieurs écrans web embarqués.
• Authentification de première partie uniquement : Votre application gère directement l'authentification. Pour les implémentations de passkeys tierces, voir cet article.
• AndroidX WebKit 1.12.1+ avec détection de fonctionnalités à l'exécution.
• Accepter la limitation de la Conditional UI pour la connexion (non prise en charge dans la WebView embarquée), non pertinente pour les paramètres de gestion.

Contexte important :

De nombreuses applications utilisent une approche hybride : une WebView système gère l'authentification OAuth initiale (où les passkeys fonctionnent de manière transparente), puis passent à une WebView embarquée après l'authentification pour gérer les passkeys dans les paramètres. Les défis surviennent lorsqu'on essaie d'utiliser les passkeys directement dans les WebViews embarquées.

Exigences techniques :

Les WebViews embarquées nécessitent une configuration supplémentaire par rapport aux WebViews système :

1. iOS : Droits (entitlements) des domaines associés, configuration du fichier AASA.
2. Android : AndroidX WebKit 1.12.1+ avec configuration WebAuthn pour la WebView (détection de fonctionnalités requise).
3. Les deux : Fichiers d'association well-known correctement configurés et Digital Asset Links.

Composants de la plateforme :

• iOS : WKWebView
• Android : android.webkit.WebView

Compromis :

• Complexité moyenne : Nécessite la configuration de la WebView (Android WebKit 1.12.1+) et la mise en place des droits (iOS).
• Adoption plus faible des passkeys : Les utilisateurs peuvent rencontrer plus de friction par rapport à une implémentation native.
• Conditional UI non prise en charge : Le remplissage automatique des passkeys dans les champs de saisie ne fonctionne pas dans la WebView embarquée d'Android.
• Support limité de la plateforme : Certaines fonctionnalités peuvent ne pas fonctionner de manière cohérente (par exemple, la création automatique de passkeys).

Lors de l'implémentation de passkeys via des WebViews, il est crucial de comprendre la distinction entre les WebViews système et les WebViews embarquées. Les trois approches décrites ci-dessus (Implémentation native, WebView système et WebView embarquée) répondent chacune à des cas d'usage différents.

Sur iOS, vous avez plusieurs options pour afficher du contenu web dans l'application :

• WKWebView est un composant WebView personnalisable qui fait partie du framework WebKit (introduit dans iOS 8). Il vous donne beaucoup de contrôle sur l'apparence et le comportement du contenu web.
• SFSafariViewController est un contrôleur de vue fourni par Apple qui agit comme un navigateur Safari léger au sein de votre application. Il utilise le moteur de Safari. Sur iOS 11+, il a un magasin de cookies distinct et ne partage pas les cookies de Safari. Utilisez ASWebAuthenticationSession lorsque le partage de session Safari est requis.
• SFAuthenticationSession / ASWebAuthenticationSession sont des sessions d'authentification web spécialisées (disponibles depuis iOS 11/12) destinées spécifiquement aux flux OAuth/OpenID ou autres flux de connexion sécurisés. Celles-ci tirent également parti de Safari en arrière-plan, mais sont axées sur les flux d'authentification et gèrent automatiquement des choses comme les cookies partagés et le Single Sign-On (SSO).

Sur Android, les principaux choix sont :

• Android WebView est le widget WebView standard (android.webkit.WebView), qui est essentiellement un mini-navigateur pouvant être intégré dans vos activités. Il est hautement personnalisable mais s'exécute dans le processus de votre application.
• Chrome Custom Tabs (CCT) est une fonctionnalité qui ouvre un onglet optimisé par Chrome dans le contexte de votre application. Les Custom Tabs apparaissent comme faisant partie de votre application mais sont alimentés par le navigateur Chrome (s'il est installé) avec des fonctionnalités telles que le pré-chargement, les cookies partagés et la barre d'URL familière pour la confiance de l'utilisateur.

Dans les sections suivantes, nous approfondirons ces types de WebView pour iOS et Android, et discuterons de celui qui pourrait être le mieux adapté aux flux d'authentification par passkey.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

La plateforme d'Apple propose les trois options de WebView listées ci-dessus. Votre choix affectera la fluidité avec laquelle les passkeys pourront être utilisés dans l'application :

Pour tester le comportement des différentes WebViews sur iOS, nous recommandons l'application WebView - WKWebView and UIWebView rendering.

WKWebView est un composant WebView polyvalent pour iOS. Les développeurs peuvent intégrer une WKWebView pour afficher du contenu web avec un haut degré de contrôle sur l'interface utilisateur et le comportement. WKWebView utilise le même moteur de rendu que Safari, il est donc très performant et prend en charge les fonctionnalités web modernes. En théorie, WKWebView peut gérer WebAuthn (et donc les passkeys) s'il est correctement configuré, mais notez que certaines fonctionnalités avancées du navigateur peuvent être restreintes pour des raisons de sécurité. Une chose à surveiller est que WKWebView, par défaut, ne partage pas les cookies ou les données du trousseau avec Safari Mobile. Les utilisateurs pourraient devoir se reconnecter car leur session WebView est isolée de la session de Safari. De plus, comme le contenu de WKWebView peut être entièrement personnalisé par l'application, l'utilisateur ne voit pas de barre d'adresse ou d'interface Safari – ce qui est excellent pour le branding, mais cela signifie que l'utilisateur a moins d'indices pour vérifier la légitimité de la page (une préoccupation anti-hameçonnage). Certaines applications ont même abusé de WKWebView pour injecter des scripts ou modifier le contenu (par exemple, il a été noté que TikTok injectait du JS de suivi via son navigateur in-app), il faut donc être prudent et utiliser WKWebView d'une manière sûre et digne de confiance pour l'utilisateur.

SFSafariViewController offre une expérience Safari au sein de l'application. Lorsque vous ouvrez une URL avec SFSafariViewController, c'est presque comme l'ouvrir dans le vrai navigateur Safari, sauf que l'utilisateur reste dans l'interface de votre application. L'avantage pour les passkeys est significatif : comme il s'agit essentiellement de Safari, le Trousseau iCloud de l'utilisateur et ses passkeys enregistrés sont accessibles. Notez que les cookies ne sont pas partagés sur iOS 11+. Cela signifie que si l'utilisateur a déjà un passkey pour votre site, Safari peut le trouver et même afficher l'autocomplétion de la Conditional UI pour une connexion facile. SFSafariViewController est moins personnalisable (vous ne pouvez pas beaucoup modifier sa barre d'outils), mais il gère automatiquement de nombreuses fonctionnalités de sécurité et de confidentialité. La barre d'URL est affichée, avec l'icône de cadenas pour HTTPS, ce qui donne aux utilisateurs l'assurance qu'ils sont sur le bon domaine. En général, SFSafariViewController est considéré comme plus sécurisé qu'une WKWebView brute et est plus simple à mettre en œuvre (Apple le fournit comme un composant prêt à l'emploi). Le principal compromis est que vous sacrifiez un certain contrôle sur l'apparence. Pour un flux d'authentification, c'est généralement acceptable. La priorité ici est la sécurité et la facilité de connexion, ce pour quoi SFSafariViewController excelle en utilisant le contexte de Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Ces classes (la seconde étant le nom plus récent et compatible Swift) sont conçues spécifiquement pour les flux de connexion comme OAuth ou OpenID Connect. Lorsque vous avez besoin d'authentifier un utilisateur via une page web (peut-être auprès d'un IdP externe), ces sessions sont le choix recommandé sur iOS. Elles sont très similaires à SFSafariViewController en ce qu'elles utilisent le navigateur Safari en arrière-plan et partagent les cookies/le stockage avec Safari. La différence clé est que SFAuthenticationSession demandera toujours à l'utilisateur que l'application veut s'authentifier en utilisant une page web (pour la sensibilisation de l'utilisateur) et elle utilisera automatiquement la session Safari existante de l'utilisateur si elle est disponible.

L'avantage est une expérience de SSO transparente – si l'utilisateur est déjà connecté au fournisseur dans Safari, cette session peut utiliser ce cookie pour éviter une autre connexion. Pour les passkeys, c'est important car cela signifie que tout identifiant passkey stocké dans le Trousseau Safari/iCloud peut également être utilisé ici. La recommandation officielle d'Apple est d'utiliser ASWebAuthenticationSession pour tout ce qui ressemble à un flux de connexion. Les avantages sont une confidentialité améliorée (votre application ne voit jamais les identifiants ou les cookies, Safari s'en charge) et un support SSO intégré. L'inconvénient est que c'est limité aux flux d'authentification (vous ne l'utiliseriez pas pour simplement afficher du contenu web arbitraire dans votre application). En résumé, si vous choisissez une approche WebView sur iOS, ASWebAuthenticationSession est généralement le meilleur choix pour implémenter les passkeys car il est sécurisé, partage l'état avec Safari et est spécialement conçu pour l'authentification.

Want to find out how many people use passkeys?

View Adoption Data

Sur Android, la décision concernant la WebView se situe entre la WebView classique et les Chrome Custom Tabs :

Pour tester le comportement des différentes WebViews sur Android, nous recommandons l'application WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) est un composant qui vous permet d'intégrer des pages web dans la mise en page de votre activité. Il est similaire à WKWebView en ce qu'il vous donne un contrôle total : vous pouvez intercepter la navigation, injecter du JavaScript, personnaliser l'interface utilisateur, etc. Il s'exécute également dans le processus de votre application. Utiliser une WebView pour les passkeys signifie que votre application charge votre page de connexion web, et cette page peut initier une cérémonie de passkey WebAuthn. L'Android WebView moderne prend en charge WebAuthn (à condition que l'implémentation de la WebView de l'appareil soit à jour via Android System WebView ou le composant Chrome). Une considération majeure : par défaut, une Android WebView ne partage pas les cookies ou les identifiants stockés avec le navigateur Chrome de l'utilisateur. Ainsi, tout passkey créé ou utilisé dans la WebView pourrait ne pas être connu de Chrome, et vice-versa. Cet isolement peut être bon pour la sécurité (votre application ne peut pas lire les cookies du navigateur), mais il pourrait forcer les utilisateurs à se reconnecter s'ils se sont déjà authentifiés dans Chrome. Un autre problème est la confiance. Une WebView simple n'affiche pas l'URL ou l'icône de cadenas SSL, donc les utilisateurs doivent faire entièrement confiance à votre application pour ne pas les hameçonner. Google a même interdit l'utilisation de WebView pour les connexions OAuth de Google en raison des risques potentiels de hameçonnage. En termes de performance, les WebViews sont correctes, mais elles peuvent être plus lentes ou plus gourmandes en mémoire que l'utilisation du navigateur par défaut de l'utilisateur, surtout si vous chargez des pages lourdes.

Les Chrome Custom Tabs (CCT) sont une approche hybride. Ils permettent à votre application d'ouvrir une page rendue par Chrome qui semble faire partie de votre application. Vous pouvez personnaliser la couleur de la barre d'outils, ajouter un logo d'application, etc., mais le contenu est rendu par Chrome dans un processus séparé. Pour les passkeys, les CCT présentent plusieurs avantages : ils partagent les cookies et les identifiants de l'utilisateur avec Chrome, ce qui signifie que si l'utilisateur a un passkey enregistré via Chrome (Google Password Manager), le Custom Tab peut y accéder. L'utilisateur verra également l'URL réelle et les indicateurs de sécurité, ce qui renforce la confiance. La performance est souvent meilleure – Chrome peut être "préchauffé" en arrière-plan pour un chargement plus rapide. Et surtout, la sécurité est forte : comme il s'agit essentiellement de l'application Chrome, des éléments comme Google Safe Browsing protègent la session, et votre application ne peut pas injecter de scripts arbitraires dans la page (prévenant certaines attaques).

L'inconvénient est que cela nécessite que l'utilisateur ait Chrome (ou un navigateur compatible) installé et à jour. La plupart des utilisateurs d'Android l'ont, mais sur certains appareils dans certaines régions, cela pourrait être un problème. Dans l'ensemble, si vous optez pour une approche web intégrée sur Android, les Chrome Custom Tabs sont recommandés pour les flux de passkeys, car ils offrent un bon équilibre entre intégration et sécurité. En fait, ils sont analogues au SFSafariViewController/ASWebAuthSession d'iOS à bien des égards – en tirant parti du navigateur par défaut pour l'authentification.

(Aparté : Il y a de nombreux parallèles entre WKWebView vs SFSafariViewController d'Apple et WebView vs CCT d'Android. Safari VC et Chrome Tabs partagent tous deux l'état du navigateur et offrent une meilleure sécurité, tandis que WKWebView/Android WebView donnent plus de contrôle mais isolent le contenu web. Pour les passkeys, le partage de l'état (cookies, magasins d'identifiants) est généralement souhaitable pour que le passkey puisse être accédé et créé de manière transparente.)

Quelle que soit l'approche d'implémentation que vous choisissez, certaines exigences techniques doivent être respectées pour activer la fonctionnalité des passkeys. Cette section fournit des conseils complets sur la configuration des fichiers d'association well-known, des droits iOS et de la configuration de la WebView Android.

Note sur les appareils gérés : Le comportement des passkeys change considérablement sur les appareils gérés où les politiques de gestion des appareils mobiles (MDM) contrôlent le stockage des identifiants. Pour tester les passkeys sur des appareils gérés, consultez notre guide.

Les flux natifs et par WebView embarquée nécessitent des fichiers d'association pour établir une confiance cryptographique entre votre application et votre domaine web. Les WebViews système (ASWebAuthenticationSession) et les Chrome Custom Tabs ne nécessitent pas d'association application-site.

Le fichier AASA établit la connexion entre votre application iOS et votre domaine web, permettant aux passkeys de fonctionner sur les deux plateformes.

Emplacement du fichier : https://votredomaine.com/.well-known/apple-app-site-association

Exigences de configuration :

• Hébergez-le à /.well-known/apple-app-site-association sur votre domaine.
• Servez-le via HTTPS avec un certificat SSL valide.
• Content-Type : application/json.
• Pas de redirections sur le chemin .well-known.
• Incluez l'ID d'équipe (Team ID) et l'ID de bundle (Bundle ID) de votre application.

Exemple de fichier AASA :

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Mise en cache AASA et tests :

Apple met en cache les fichiers AASA de manière agressive (jusqu'à 24-48 heures) via un CDN, ce qui peut compliquer le développement et les tests. Pour contourner la mise en cache pendant le développement :

1. Activez le mode développeur sur votre appareil de test.
2. Ajoutez ?mode=developer à votre domaine associé dans Xcode.
3. Cela force iOS à récupérer la dernière version du fichier AASA directement depuis votre serveur.

⚠️ Important : N'utilisez PAS ?mode=developer dans les versions de production. Ce paramètre est réservé au développement. L'utiliser en production empêchera iOS de détecter correctement votre fichier AASA, ce qui cassera la fonctionnalité des passkeys.

Validation : Utilisez le validateur AASA d'Apple pour vérifier votre configuration.

Android utilise les Digital Asset Links pour vérifier la relation entre votre application et votre site web.

Emplacement du fichier : https://votredomaine.com/.well-known/assetlinks.json

Exigences de configuration :

• Hébergez-le à /.well-known/assetlinks.json sur votre domaine.
• Servez-le via HTTPS avec un certificat valide.
• Content-Type : application/json.
• Incluez l'empreinte SHA256 de votre application (depuis le certificat de signature).

Exemple de fichier assetlinks.json :

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Validation : Utilisez le générateur de Digital Asset Links de Google pour créer et vérifier votre configuration.

Les applications iOS nécessitent des droits appropriés pour accéder à la fonctionnalité des passkeys. Les exigences diffèrent légèrement en fonction de votre approche d'implémentation.

Le fichier de droits (souvent nommé Runner.entitlements dans les applications Flutter ou VotreApp.entitlements dans les projets iOS natifs) définit des permissions et capacités spéciales accordées par le système d'Apple. Pour les passkeys, ce fichier configure les domaines associés (Associated Domains).

Emplacement du fichier : Généralement dans votre projet Xcode à ios/Runner/Runner.entitlements.

L'implémentation native et la WebView embarquée nécessitent la capacité des domaines associés pour lier votre application à votre domaine web. La WebView système (ASWebAuthenticationSession) ne requiert pas cela car elle s'exécute dans le contexte de Safari.

Configuration dans Xcode :

1. Ouvrez votre projet dans Xcode.
2. Sélectionnez votre cible d'application.
3. Allez à l'onglet "Signing & Capabilities".
4. Cliquez sur "+ Capability" et ajoutez "Associated Domains".
5. Ajoutez votre domaine avec le préfixe webcredentials:.

Exemple de configuration :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:votredomaine.com</string>
        <string>webcredentials:sousdomaine.votredomaine.com</string>
    </array>
</dict>
</plist>

Domaines multiples : Si votre application doit fonctionner avec plusieurs domaines, vous pourriez avoir besoin des Related Origin Requests (ROR).

Les WebViews embarquées d'Android ont obtenu le support natif de WebAuthn avec AndroidX WebKit 1.12, éliminant le besoin de code de pont JavaScript personnalisé. La WebView système (Chrome Custom Tabs) ne nécessite aucune configuration – les identifiants fonctionnent automatiquement.

Exigences :

• AndroidX WebKit 1.12.1 ou plus récent (1.14.0+ recommandé).
• Digital Asset Links configurés.
• APK WebView avec support de WebAuthn (vérifiez via la détection de fonctionnalités).
• Note : la bibliothèque AndroidX Credentials n'est PAS requise pour WebAuthn dans une WebView, seulement pour les implémentations entièrement natives.

Implémentation :

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Vérifier si l'authentification web est prise en charge
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Activer l'authentification web
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Activer JavaScript
    webView.settings.javaScriptEnabled = true
}

Points clés :

• Pas besoin de pont JavaScript : WebAuthn fonctionne nativement dans la WebView.
• Détection de fonctionnalités requise : Vérifiez toujours WebViewFeature.WEB_AUTHENTICATION à l'exécution.
• Conditional UI non prise en charge : mediation:"conditional" (remplissage automatique des passkeys dans les champs de saisie) ne fonctionne pas dans la WebView embarquée.
• Stratégie de repli : Si la fonctionnalité n'est pas disponible, utilisez plutôt les Chrome Custom Tabs.

Notes de version :

• Utilisez WebKit 1.12.1 ou plus récent (la version 1.12.0 avait un problème de disponibilité à l'exécution).
• Le support de la fonctionnalité dépend de la version de l'APK WebView de l'utilisateur – les anciennes versions de l'APK sur l'appareil n'exposeront pas la fonctionnalité.

Avant AndroidX WebKit 1.12.0, le support natif de WebAuthn n'existait pas dans la WebView embarquée. Les équipes devaient soit :

1. Utiliser les Chrome Custom Tabs ou l'Auth Tab (recommandé).
2. Construire un pont JavaScript personnalisé.

Si vous devez prendre en charge d'anciennes versions d'Android ou des appareils sans APK WebView mis à jour, consultez le guide d'intégration WebView du Credential Manager d'Android pour l'approche avec le code de pont. Cependant, nous recommandons fortement d'utiliser l'approche native de WebKit 1.12.1+ pour les applications modernes.

Recommandation : Utilisez le support natif de WebAuthn avec AndroidX WebKit 1.12.1+. Si indisponible à l'exécution, repliez-vous sur les Chrome Custom Tabs qui offrent un excellent support des passkeys avec des identifiants partagés.

Lors de l'implémentation de passkeys dans des applications natives, vous devez établir une confiance entre votre application et votre ou vos domaines web. Cette section explique comment gérer les domaines uniques, les multiples domaines liés (ROR) et comment vérifier que vos fichiers d'association well-known sont correctement configurés.

Pour les applications utilisant un domaine unique (par exemple, kayak.com), vous avez besoin de :

• Un fichier AASA pour iOS à https://kayak.com/.well-known/apple-app-site-association
• Un fichier assetlinks.json pour Android à https://kayak.com/.well-known/assetlinks.json
• Droit des domaines associés configuré avec webcredentials:kayak.com

Les origines liées (ROR) sont une fonctionnalité de WebAuthn qui permet à un unique ensemble de passkeys de fonctionner sur plusieurs domaines liés (par exemple, kayak.com, kayak.de, kayak.co.uk). ROR utilise le point de terminaison /.well-known/webauthn sur chaque site pour définir les origines liées, PAS les fichiers AASA ou assetlinks.

Points clés :

• Configuration ROR : Chaque domaine héberge /.well-known/webauthn avec la liste des origines liées.
• Fichiers d'association d'application (AASA/assetlinks) : Utilisés uniquement pour mapper les applications à leurs sites web correspondants.
• WebView embarquée d'iOS 18+ : Prend en charge ROR lorsqu'il est correctement configuré.
• Droits des domaines associés : Incluez tous les domaines avec lesquels votre application doit s'authentifier.

Exemple de configuration :

Si votre application fonctionne avec kayak.com et kayak.de, les deux domaines doivent :

• Héberger leurs fichiers AASA respectifs avec le même ID d'équipe et ID de bundle.
• Être listés dans les droits des domaines associés de votre application.
• Avoir des fichiers well-known correctement configurés et accessibles.

Avant de passer en production, vérifiez que vos fichiers well-known sont correctement configurés et accessibles. Apple et Google fournissent des URL de test basées sur CDN pour vérifier la disponibilité des fichiers :

Utilisation de ces URL de test :

• Cliquez sur les liens pour vérifier si Apple/Google peuvent récupérer vos fichiers well-known.
• Le paramètre ?nocache=1 d'Apple force une nouvelle récupération, contournant le cache du CDN.
• Si les fichiers ne sont pas accessibles via ces URL, la fonctionnalité des passkeys ne fonctionnera pas dans votre application.
• Remplacez kayak.com ou kayak.de par votre ou vos propres domaines dans les modèles d'URL ci-dessus.

Piège de test : Assurez-vous que tous les domaines ont des fichiers well-known correctement configurés. Un fichier manquant ou mal configuré sur un domaine peut casser la fonctionnalité des passkeys pour ce domaine.

Choisir la bonne approche d'implémentation dépend de l'architecture d'authentification de votre application, des exigences OAuth et du besoin de contrôle de session. Utilisez cet arbre de décision pour déterminer la meilleure voie à suivre.

Commencez par ces questions clés :

1. Votre application utilise-t-elle une connexion basée sur OAuth (OAuth2, OIDC, fournisseurs de connexion sociale) ?

   • Oui → WebView système (Section 1.2)
     • iOS : Utilisez ASWebAuthenticationSession
     • Android : Utilisez les Chrome Custom Tabs
     • Excellent support OAuth avec des identifiants partagés

2. Voulez-vous réutiliser l'authentification web dans une enveloppe de type natif (pas de barre d'URL, contrôle total de l'interface utilisateur) ?

   • Oui → WebView embarquée (Section 1.3) avec configuration
   • iOS : WKWebView + droits des domaines associés
   • Android : WebView + configuration AndroidX WebKit 1.12.1+
   • Fournit une apparence de type natif tout en réutilisant les composants web
   • Note : La Conditional UI n'est pas prise en charge dans la WebView embarquée
   • Non → Envisagez une WebView système ou une implémentation native

3. Développez-vous une nouvelle application native ou avez-vous des écrans de connexion natifs ?

   • Oui → Implémentation native (Section 1.1)
     • Meilleure expérience utilisateur
     • Authentification instantanée et silencieuse
     • Nécessite un développement spécifique à la plateforme

4. Avez-vous une authentification web existante que vous souhaitez réutiliser ?

   • Oui → WebView système pour une implémentation rapide
   • Non → Implémentation native pour une UX optimale

Voici comment chaque approche se comporte sur les dimensions clés :

Explications des dimensions :

• Créer des passkeys : Facilité avec laquelle les utilisateurs peuvent créer des passkeys via cette approche.
• Utiliser des passkeys : L'expérience d'authentification lors de l'utilisation de passkeys existants.
• Gérer les passkeys : Comment les utilisateurs voient, modifient ou suppriment les passkeys.
• Complexité technique : Effort de développement et maintenance continue.
• Support OAuth : Dans quelle mesure l'approche gère les flux d'authentification OAuth2/OIDC.
• Temps de mise en place : Chronologie d'implémentation typique.

Recommandé : WebView système

Si votre application s'authentifie via OAuth2, OIDC ou des fournisseurs de connexion sociale (Google, GitHub, Microsoft, etc.), la WebView système est le choix optimal :

• iOS : ASWebAuthenticationSession est spécialement conçu pour les flux OAuth.
• Android : Les Chrome Custom Tabs offrent une intégration OAuth transparente.
• Avantages : Code natif minimal, partage automatique des identifiants.
• Implémentation : Ajoutez WebAuthn à votre page d'authentification web, puis chargez-la via une WebView système.

Exemple : Des applications de voyage comme kayak.com et kayak.de utilisent OAuth pour l'authentification. La WebView système leur permet de maintenir leur infrastructure OAuth existante tout en ajoutant le support des passkeys via leurs pages d'authentification web.

Recommandé : Approche hybride

Utilisez une WebView système pour l'authentification OAuth initiale, puis une WebView embarquée pour les sessions post-authentification :

1. Authentification initiale : La WebView système gère la connexion OAuth + passkey.
2. Gestion de session : Passez à une WebView embarquée pour le contenu web authentifié où vous avez besoin de contrôle sur les cookies/sessions.
3. Configuration technique : Configurez les exigences des WebViews système et embarquées – pour Android, assurez-vous qu'AndroidX WebKit 1.12.1+ est inclus (voir la section 5).

Quand l'utiliser : Applications qui s'authentifient via OAuth mais qui ont ensuite besoin d'afficher du contenu web authentifié où une manipulation directe de la session est requise.

Recommandé : Implémentation native

Vous partez de zéro ou avez des écrans natifs ? Optez pour le tout natif :

• iOS : Utilisez le framework AuthenticationServices.
• Android : Utilisez l'API Credential Manager.
• Avantages : Meilleure UX, authentification instantanée, contrôle total.
• Avantage unique : Utilisez preferImmediatelyAvailableCredentials pour afficher une superposition de passkeys automatique au démarrage de l'application - exclusif aux implémentations natives et offrant les taux de conversion les plus élevés.
• Recommandation de SDK : Utilisez les SDK de Corbado (iOS, Android) pour accélérer le développement avec une gestion des cas limites testée en production.

Pour les nouvelles applications : Nous recommandons fortement de construire une connexion native dès le premier jour. Cela vous prépare pour une UX optimale et évite les migrations futures de WebView vers le natif.

Recommandé : Migration par étapes

• Phase 1 : Passkeys via WebView système - Ajoutez le support des passkeys à la connexion web existante, chargez-la via une WebView système (ASWebAuthenticationSession/Chrome Custom Tabs). Gain rapide avec un minimum de code natif.
• Phase 2 : Interception native - Ajoutez une vérification de passkey native avant d'afficher la WebView. Exemple : kayak.com tente d'abord une authentification par passkey native, et se rabat sur la WebView si nécessaire. Fournit une connexion biométrique rapide tout en maintenant la rétrocompatibilité.
• Phase 3 : Tout natif - Migrez progressivement vers une authentification native pour les utilisateurs de passkeys, en conservant la WebView pour les méthodes héritées.

Cette approche par étapes permet des améliorations incrémentielles sans perturber les utilisateurs existants.

Voir la section 5 pour des instructions de configuration détaillées.

Tester les passkeys dans les applications natives nécessite une approche structurée et multi-niveaux. Suivez la pyramide des tests : tests unitaires (logique isolée), tests d'intégration (cérémonie WebAuthn sur simulateurs/émulateurs) et tests système (de bout en bout sur des appareils physiques).

Catégories de tests essentielles :

• Parcours principaux : Inscription, authentification, flux multi-appareils, suppression de passkey
• Couverture des plateformes : iOS (natif), Android (natif), navigateurs web sur différentes versions d'OS
• Association de domaine : Vérifier que les fichiers AASA (iOS) et les Digital Asset Links (Android) sont accessibles
• Flux d'annulation : Tester l'annulation par l'utilisateur aux invites de l'OS et sur les écrans biométriques
• Gestion des erreurs : Échecs du backend, temps d'attente réseau, non-concordance des identifiants
• Cas limites : Verrouillage d'écran désactivé, Trousseau iCloud/Gestionnaire de mots de passe Google désactivé
• Flux OAuth : Intégration complète OAuth + passkey de bout en bout
• Appareils gérés : Environnements contrôlés par MDM
• Gestionnaires tiers : Compatibilité avec 1Password, Bitwarden, Dashlane
• Authentification multi-appareils : Flux par QR code et tests de transport hybride
• Spécifique à la WebView embarquée : Si vous utilisez une WebView embarquée, vérifiez la configuration de WebKit 1.12.1+ sur Android
• Surveillance en production : Tableau de bord pour les taux de réussite, les échecs et la latence

Pour des conseils de test complets, y compris des stratégies d'automatisation, des pièges spécifiques à chaque plateforme et une liste de contrôle complète avant le lancement, consultez notre guide dédié.

Envisagez de proposer aux utilisateurs de créer des passkeys après une connexion traditionnelle réussie (mot de passe, OAuth). Cette approche de conversion progressive :

• Ne perturbe pas les flux d'authentification existants.
• Permet une dégradation gracieuse si l'utilisateur refuse.
• Augmente l'adoption des passkeys au fil du temps sans forcer les changements.
• Fonctionne bien avec les trois approches d'implémentation.

Exemple : Après une connexion OAuth via une WebView système, affichez une invite native : "Activer une connexion plus rapide avec Face ID ?" Si accepté, créez un passkey via la page web chargée dans la WebView système.

Décider comment implémenter les passkeys - via une implémentation native, une WebView système ou une WebView embarquée - est un choix de conception crucial qui a un impact sur la sécurité, l'expérience utilisateur et la complexité du développement. Il n'y a pas de réponse unique.

Pour les applications basées sur OAuth : La WebView système (ASWebAuthenticationSession, Chrome Custom Tabs) est le point de départ recommandé. Elle offre un excellent support OAuth, un effort d'implémentation minimal et un partage automatique des identifiants.

Pour les applications native-first : Optez pour le natif le plus tôt possible. Une connexion par passkey native offre l'UX la plus fluide avec des capacités exclusives comme preferImmediatelyAvailableCredentials, qui permet une superposition automatique de passkeys au démarrage de l'application - ce que les implémentations WebView ne peuvent pas fournir. Avec iOS et Android offrant désormais un support de premier ordre pour les passkeys, les succès concrets démontrent une forte adoption. L'outillage (y compris les SDK open-source et les bibliothèques de plateforme) a mûri pour rendre l'intégration native réalisable dans des délais raisonnables. Bien que vous deviez être attentif aux politiques de gestion des appareils, à la synchronisation multi-appareils et aux fournisseurs tiers, ces défis peuvent être gérés avec une ingénierie et des tests minutieux. Le résultat est une connexion à l'application qui ravit les utilisateurs par sa facilité et sa rapidité tout en améliorant considérablement la sécurité.

Pour les besoins de cadres WebView embarqués : La WebView embarquée est couramment utilisée dans deux scénarios concrets. Premièrement, les applications basées sur OAuth utilisent souvent une WebView système pour le flux de connexion initial, puis passent à une WebView embarquée pour afficher les options de gestion des passkeys dans les écrans de paramètres où le contrôle de la session est nécessaire - bien que certaines applications simplifient cela en gardant la WebView système pour les deux flux. Deuxièmement, les applications qui avaient déjà intégré leur flux d'authentification dans des cadres WebView avant d'adopter les passkeys continuent ce modèle pour des raisons de cohérence. La WebView embarquée avec support natif de WebAuthn (AndroidX WebKit 1.12.1+) nécessite une configuration et une mise en place (permissions, droits, paramètres WebView) mais n'a plus besoin de code de pont JavaScript personnalisé. Notez que la Conditional UI n'est pas prise en charge dans la WebView embarquée. Choisissez cette approche lorsque vous maintenez des modèles d'authentification embarqués existants ou lorsque vous avez besoin de contrôle sur la session/les cookies pour les écrans post-authentification.

En fin de compte, les passkeys dans les applications natives représentent un énorme bond en avant tant en termes de commodité pour l'utilisateur que de sécurité. Qu'ils soient implémentés via une approche native, une WebView système ou une WebView embarquée, ils éliminent les risques de hameçonnage et le fardeau de la gestion des mots de passe pour vos utilisateurs. Les implémentations concrètes comme l'intégration de passkeys dans l'application native de VicRoads démontrent que les approches native-first offrent la plus grande adoption et satisfaction des utilisateurs lorsqu'elles sont correctement exécutées avec des fonctionnalités comme les superpositions automatiques de passkeys. En suivant les meilleures pratiques pour une authentification conviviale et en choisissant l'approche d'implémentation qui correspond à l'architecture de votre application - native-first pour les nouvelles applications, WebView système pour les flux OAuth, ou WebView embarquée pour les modèles embarqués existants - vous pouvez offrir des connexions biométriques sans mot de passe qui réalisent vraiment la vision des passkeys : une authentification simple, sûre et agréable pour tous.

Si les passkeys ne fonctionnent pas dans votre application native, vérifiez ces problèmes courants par approche d'implémentation :

• Fichiers servis via HTTPS avec un certificat valide.
• Type MIME correct : application/json.
• Pas de redirections sur le chemin .well-known.
• iOS : L'ID d'équipe et l'ID de bundle correspondent exactement dans le fichier AASA.
• Android : L'empreinte SHA256 correspond à votre certificat de signature dans assetlinks.json.
• L'ID de la partie de confiance (Relying Party) correspond à votre domaine (sans protocole, ni port).
• Pas de barres obliques finales dans l'ID de RP.
• Origine WebAuthn : https://votre-domaine.com (pas app://).

• iOS : Capacité des domaines associés activée dans Xcode avec webcredentials:votredomaine.com.
• Android : Digital Asset Links déclarés dans AndroidManifest.xml.
• L'utilisateur a activé le verrouillage de l'écran (biométrique ou PIN).
• Testez avec le validateur AASA d'Apple et l'outil Digital Asset Links de Google.
• Vérifiez que le fichier Runner.entitlements contient les bons domaines associés.

• iOS : Utilisation de ASWebAuthenticationSession (recommandé) ou SFSafariViewController.
• Android : Utilisation des Chrome Custom Tabs (pas une WebView simple).
• iOS : Vérifiez que les domaines associés sont configurés si nécessaire.
• Testez que les cookies/identifiants sont partagés avec le navigateur système.
• Vérifiez que la page d'authentification web a une implémentation WebAuthn correcte.

• iOS : Configurée avec les droits appropriés.
• iOS : Les domaines associés incluent tous les domaines pertinents.
• iOS : Fichier AASA accessible et correctement formaté.
• iOS : Testez avec ?mode=developer pendant le développement (à retirer pour la production).
• Android : AndroidX WebKit 1.12.1+ (ou plus récent) inclus dans le projet.
• Android : Vérification de la fonctionnalité à l'exécution pour WebViewFeature.WEB_AUTHENTICATION.
• Android : setWebAuthenticationSupport() appelé avec WEB_AUTHENTICATION_SUPPORT_FOR_APP.
• Android : JavaScript activé dans les paramètres de la WebView.
• Android : La version de l'APK WebView de l'utilisateur prend en charge la fonctionnalité WebAuthn (utilisez la détection de fonctionnalité, pas la version de l'OS).
• Conditional UI non utilisée (non prise en charge dans la WebView embarquée).
• Repli sur les Chrome Custom Tabs si la fonctionnalité WebAuthn n'est pas disponible.

• Vérifiez si l'utilisateur a un fournisseur d'identifiants non par défaut actif (1Password, Bitwarden, etc.).
• Vérifiez que le fournisseur prend en charge les passkeys (tous les gestionnaires de mots de passe ne le font pas).
• Testez avec le gestionnaire d'identifiants natif de la plateforme (Trousseau iCloud, Gestionnaire de mots de passe Google).

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Signifie généralement : Droits manquants (iOS) ou fonctionnalité WebView non disponible/activée (WebView embarquée Android).
• Vérifiez : Configuration des domaines associés, accessibilité du fichier AASA, version de WebKit, détection de fonctionnalité, appel de setWebAuthenticationSupport().

Aucune invite de passkey n'apparaît

• Pourrait signifier : AASA/assetlinks.json ne se charge pas, mauvais type de WebView, fichier AASA mis en cache.
• Essayez : Validez les fichiers d'association, utilisez ?mode=developer sur iOS pour les tests, vérifiez le type de WebView.

Pour un débogage détaillé, consultez notre article sur les ID de partie de confiance dans les applications natives.

SDK natifs de Corbado :

• SDK iOS (Swift)
• SDK Android (Kotlin)
• Package Flutter

Documentation des plateformes :

• Apple : Supporting Passkeys
• Google : Credential Manager

Outils de validation :

• Validateur AASA d'Apple
• Générateur de Digital Asset Links de Google