Clés d'accès pour applications natives : Implémentation native vs WebView

Remarque : System WebView et Embedded WebView sont souvent combinés, System WebView gérant la connexion (avec partage automatique des identifiants), puis Embedded WebView affichant la gestion des clés d'accès dans les paramètres.

Facteurs de décision clés :

• Connexion basée sur OAuth ? → System WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Réutilisation de l'authentification web dans une structure native ? → Embedded WebView (WKWebView, Android WebView avec WebKit 1.12.1+)
• Création d'une application prioritairement native ? → Implémentation Native (Apple AuthenticationServices, Google Credential Manager)

Les plateformes mobiles modernes offrent trois approches distinctes pour intégrer les clés d'accès dans votre application native, chacune présentant des compromis différents en matière d'expérience utilisateur, de complexité technique et de compatibilité OAuth :

1. Implémentation Native : Intégrez les flux de clés d'accès directement dans votre application à l'aide des API de la plateforme (iOS AuthenticationServices, Android Credential Manager). Offre la meilleure expérience utilisateur avec une authentification biométrique fluide, mais nécessite un effort technique d'implémentation moyen à élevé.

2. System WebView : Utilisez le composant navigateur de la plateforme (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) pour gérer l'authentification. Excellent pour les flux de connexion basés sur OAuth et partage les identifiants avec le navigateur du système.

3. Embedded WebView : Intégrez une vue web personnalisable (iOS WKWebView, Android WebView) au sein de votre application pour réutiliser l'authentification web avec un squelette d'application natif. Offre une apparence native sans barre d'URL et un contrôle total sur l'interface utilisateur de la vue web. Nécessite une configuration supplémentaire comprenant des autorisations et des droits (iOS), et une configuration WebView avec AndroidX WebKit 1.12.1+ (Android) pour activer la fonctionnalité des clés d'accès.

Le bon choix dépend de l'architecture d'authentification de votre application, si vous utilisez des fournisseurs OAuth, du niveau de contrôle dont vous avez besoin sur l'interface utilisateur et si vous construisez une application prioritairement native ou si vous réutilisez des composants web.

Livre blanc Passkey entreprise. Conseils pratiques, modèles de déploiement et KPIs pour les programmes passkeys.

Obtenir le livre blanc

Une implémentation native des clés d'accès offre l'expérience utilisateur optimale, avec des flux d'authentification intégrés directement dans l'interface de votre application à l'aide des 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 :

• Création d'une nouvelle application native ou refonte de l'authentification vers des écrans natifs
• Volonté d'offrir la meilleure expérience utilisateur possible avec une authentification instantanée et silencieuse
• Invites automatiques de clés d'accès au démarrage de l'application : Les implémentations natives peuvent utiliser preferImmediatelyAvailableCredentials pour afficher automatiquement une superposition de clés d'accès lorsque les clés d'accès sont disponibles, offrant l'expérience de connexion la plus rapide sans exiger la saisie d'un identifiant
• Besoin d'un contrôle total sur l'interface et le flux d'authentification
• Prêt à investir dans une implémentation spécifique à la plateforme (iOS Swift, Android Kotlin)

Avantage clé : preferImmediatelyAvailableCredentials()

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

Le diagramme ci-dessous illustre comment l'authentification native offre un parcours utilisateur plus rapide par rapport à l'approche Conditional UI de WebView :

La superposition automatique native offre une UX supérieure avec des taux d'utilisation de clés d'accès plus élevés, car l'authentification commence immédiatement au lancement de l'application, tandis que les implémentations WebView exigent que les utilisateurs interagissent d'abord avec les champs de saisie.

Aperçu des exigences techniques :

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

1. Fichiers d'association Application-Domaine hébergés sous /.well-known/
2. Identifiant de partie utilisatrice (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 clés d'accès créées sur votre site web fonctionnent de manière transparente dans votre application et vice versa.

L'implémentation native des clés d'accès sur iOS implique 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 clés d'accès
• Trois modes d'interface distincts pour gérer les connexions par clés d'accès :
  • Connexion par champ de texte : Champ de nom d'utilisateur traditionnel avec la connexion par clé d'accès démarrant lors de la soumission du bouton
  • Superposition modale de clés d'accès : Boîte de dialogue du système d'exploitation listant les clés d'accès disponibles
  • Interface conditionnelle (Conditional UI) : Suggestions de clés d'accès 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 frustrer les tests. Solution : Activez le mode développeur sur votre appareil de test et ajoutez ?mode=developer à votre URL AASA pour forcer des récupérations actualisées
• Tests de performance : Testez avec des comptes iCloud contenant des centaines d'identifiants pour observer la latence dans des conditions réelles. La superposition du système peut montrer un léger retard avec de nombreuses clés d'accès stockées

L'implémentation native des clés d'accès 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 clés d'accès
• GetCredentialRequest : Pour l'authentification par clé d'accès
• Deux modes d'interface principaux :
  • Connexion par champ de texte : Champ de nom d'utilisateur traditionnel avec la connexion par clé d'accès démarrant lors de la soumission du bouton
  • Superposition modale de clés d'accès : Boîte de dialogue du système d'exploitation listant les clés d'accès disponibles

Remarque : Android ne dispose pas actuellement des suggestions clavier de l'interface conditionnelle d'iOS dans les applications natives (bien que le Conditional UI fonctionne dans les applications web)

L'implémentation native des clés d'accès présente des défis importants et des leçons apprises : l'intégration au niveau du système d'exploitation peut faire remonter des problèmes sur différents appareils et versions d'OS.

1. Par exemple, notre équipe a rencontré des problèmes tels que la mise en cache agressive par Apple du fichier apple-app-site-association (utilisé pour lier les identifiants de l'application et du web) et de subtiles différences d'interface dans certaines invites biométriques d'équipements Android.
2. De plus, considérez que dans certains scénarios d'entreprise, la synchronisation des clés d'accès peut être désactivée par stratégie sur les appareils gérés. Dans les environnements d'entreprise où la synchronisation iCloud Keychain ou Google Password Manager est désactivée, les clés d'accès deviennent liées à l'appareil et ne seront pas transférées - un scénario important à anticiper (par exemple, s'assurer que les utilisateurs peuvent toujours se connecter s'ils obtiennent un nouveau téléphone).
3. En outre, les applications de gestion d'identifiants 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 clés d'accès, prenant la priorité sur le gestionnaire d'identifiants natif de la plateforme.

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

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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

Quand choisir System WebView :

• Votre application utilise une connexion basée sur OAuth : System WebView est l'approche recommandée pour les flux OAuth2/OIDC, offrant une authentification sécurisée
• Authentification web existante que vous souhaitez réutiliser dans les applications mobiles
• Besoin de prendre en charge plusieurs méthodes d'authentification (mots de passe, connexion sociale, clés d'accès) sans reconstruire nativement
• Volonté de maintenir une base de code d'authentification unique à travers le web et le mobile

Avantages clés :

• Compatibilité OAuth : Conçu spécifiquement 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 : Code natif minimal requis
• UX cohérente : Interface de navigateur familière en laquelle les utilisateurs ont 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 clé d'accès à leurs applications mobiles via des superpositions WebView sur des pages d'authentification web existantes. Cela fonctionne bien lorsque les refontes d'authentification entièrement natives ne sont pas immédiatement réalisables.

iOS propose deux composants principaux de System WebView pour l'authentification :

ASWebAuthenticationSession (Recommandé pour l'Authentification) :

• Conçu spécifiquement pour OAuth/OIDC et les flux de connexion sécurisés
• Demande automatiquement à l'utilisateur si l'application peut l'authentifier
• Partage les cookies et les identifiants avec Safari
• Prend en charge les clés d'accès 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 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 propulsé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é
• Possibilité 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 clés d'accès stockées.

Testez les passkeys dans une démo en direct.

Tester les passkeys

Les Embedded WebViews (vues web intégrées) offrent un contrôle total sur le rendu du contenu web dans 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 clés d'accès.

Quand choisir Embedded WebView :

• Expérience de type natif : Votre application intègre déjà l'authentification dans une vue web personnalisée pour conserver un aspect et une convivialité natifs, et vous souhaitez maintenir 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 une fois l'authentification OAuth terminée
• Flux d'authentification existant où l'authentification System WebView renvoie un code d'autorisation mais aucune session dans les contextes intégrés
• Obligation de maintenir l'état d'authentification sur plusieurs écrans web intégrés
• Authentification propriétaire uniquement : Votre application gère l'authentification directement (pour les implémentations de clés d'accès tierces, voir ici)
• AndroidX WebKit 1.12.1+ avec détection de fonctionnalité à l'exécution
• Acceptation de la limitation de Conditional UI pour la connexion (non prise en charge dans Embedded WebView), non pertinent pour les paramètres de gestion

Contexte important :

De nombreuses applications utilisent une approche hybride : System WebView gère l'authentification OAuth initiale (où les clés d'accès fonctionnent parfaitement), puis bascule vers Embedded WebView pour post-authentification afin de gérer les clés d'accès dans les paramètres. Le défi survient lors de la tentative d'utilisation des clés d'accès directement dans les Embedded WebViews.

Exigences techniques :

Les Embedded WebViews nécessitent une configuration supplémentaire par rapport aux System WebViews :

1. iOS : Droits Associated Domains, configuration du fichier AASA
2. Android : AndroidX WebKit 1.12.1+ avec configuration WebAuthn WebView (détection de fonctionnalité 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 WebView (Android WebKit 1.12.1+) et la configuration des droits (iOS)
• Adoption de clés d'accès plus faible : Les utilisateurs peuvent rencontrer plus de friction par rapport au natif
• Conditional UI non pris en charge : Le remplissage automatique des clés d'accès dans les champs de saisie ne fonctionne pas dans Android Embedded WebView
• Support de plateforme limité : Certaines fonctionnalités peuvent ne pas fonctionner de manière cohérente (ex : création automatique de clés d'accès)

Lors de l'implémentation de clés d'accès via WebViews, il est crucial de comprendre la distinction entre System WebViews et Embedded WebViews. Les trois approches décrites ci-dessus (Implémentation Native, System WebView et Embedded WebView) répondent chacune à des cas d'utilisation différents.

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

• WKWebView est un 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 allégé au sein de votre application. Il utilise le moteur de Safari. Sur iOS 11+, il a un magasin de cookies séparé et ne partage pas les cookies 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 de connexion OAuth/OpenID ou autres. Celles-ci utilisent également Safari en arrière-plan, mais sont axées sur les flux d'authentification et gèrent automatiquement des éléments tels que les cookies partagés et l'authentification unique (SSO).

Sur Android, les choix principaux 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 alimenté par Chrome dans le contexte de votre application. Les Custom Tabs apparaissent comme faisant partie de votre application mais sont propulsé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 des utilisateurs.

Dans les sections suivantes, nous examinerons plus en détail ces types de WebView pour iOS et Android, et discuterons de celui qui convient le mieux aux flux d'authentification par clés d'accès.

Abonnez-vous à notre Substack passkeys pour les dernières actualités.

S'abonner

La plateforme d'Apple fournit les trois options WebView énumérées ci-dessus. Votre choix affectera la fluidité avec laquelle les clés d'accès peuvent être utilisées dans l'application :

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

WKWebView est un composant WebView polyvalent pour iOS. Les développeurs peuvent intégrer un WKWebView pour rendre 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 clés d'accès) s'il est configuré correctement, 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 Mobile Safari. Les utilisateurs devront peut-être se connecter à nouveau car leur session WebView est isolée de la session de Safari. De plus, parce que le contenu de WKWebView peut être entièrement personnalisé par l'application, l'utilisateur ne voit pas de barre d'adresse ni d'interface Safari – ce qui est idéal pour l'image de marque, mais cela signifie que l'utilisateur a moins de repères pour vérifier la légitimité de la page (une préoccupation pour la lutte contre le phishing). Certaines applications ont même abusé de WKWebView pour injecter des scripts ou modifier du contenu (ex : TikTok a été remarqué pour l'injection de JS de suivi via son navigateur intégré), il faut donc veiller à utiliser WKWebView de manière sûre et digne de confiance pour l'utilisateur.

SFSafariViewController offre une expérience Safari intégrée à l'application. Lorsque vous ouvrez une URL avec SFSafariViewController, c'est presque comme l'ouvrir dans le véritable navigateur Safari, sauf que l'utilisateur reste dans l'interface de votre application. L'avantage pour les clés d'accès est significatif : parce que c'est essentiellement Safari, le trousseau iCloud de l'utilisateur et les clés d'accès enregistrées sont accessibles. Notez que les cookies ne sont pas partagés sur iOS 11+. Cela signifie que si l'utilisateur possède déjà une clé d'accès pour votre site, Safari peut la trouver et même afficher la saisie automatique de l'interface conditionnelle pour une connexion facile. SFSafariViewController est moins personnalisable (vous ne pouvez pas beaucoup modifier sa barre d'outils), mais il gère automatiquement un grand nombre de 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 se trouvent sur le bon domaine. En général, SFSafariViewController est considéré comme plus sécurisé qu'un WKWebView brut et est plus simple à implémenter (Apple le fournit prêt à l'emploi). Le principal compromis est que vous sacrifiez une partie du 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 dans quoi SFSafariViewController excelle en utilisant le contexte de Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Ces classes (la dernière étant le nouveau nom adapté à Swift) sont conçues spécifiquement pour les flux de connexion comme OAuth ou OpenID Connect. Lorsque vous devez 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 dans la mesure où elles utilisent le navigateur Safari en arrière-plan et partagent les cookies/le stockage avec Safari. La principale différence est que SFAuthenticationSession avertira toujours l'utilisateur que l'application souhaite s'authentifier à l'aide d'une page web (pour le sensibiliser) et utilisera automatiquement la session Safari existante de l'utilisateur si elle est disponible.

L'avantage est une expérience 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 clés d'accès, c'est important car cela signifie que toute clé d'accès stockée dans Safari/le trousseau iCloud peut également être utilisée ici. La recommandation officielle d'Apple est d'utiliser ASWebAuthenticationSession pour tout ce qui ressemble à un flux de connexion. Les avantages sont une confidentialité renforcée (votre application ne voit jamais les identifiants ou les cookies, Safari s'en occupe) et un support SSO intégré. L'inconvénient est que c'est limité aux flux d'authentification (vous ne l'utiliseriez pas pour afficher un 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 des clés d'accès car c'est sécurisé, cela partage l'état avec Safari et c'est conçu pour l'authentification.

Découvrez combien de personnes utilisent réellement les passkeys.

Voir les données d'adoption

Sur Android, le choix de WebView se fait entre le WebView classique et Chrome Custom Tabs :

Pour tester le comportement des différents WebViews sous 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 présentation de votre activité. C'est similaire à WKWebView dans la mesure où 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 un WebView pour les clés d'accès signifie que votre application charge votre page de connexion web, et cette page peut initier une cérémonie WebAuthn. Les Android WebView modernes prennent en charge WebAuthn (à condition que l'implémentation WebView de l'appareil soit à jour via Android System WebView ou le composant Chrome). Une considération majeure : par défaut, un Android WebView ne partage pas les cookies ni les identifiants enregistrés avec le navigateur Chrome de l'utilisateur. Ainsi, toute clé d'accès créée ou utilisée dans le WebView pourrait ne pas être connue de Chrome, et vice versa. Cette isolation peut être une bonne chose pour la sécurité (votre application ne peut pas lire les cookies du navigateur), mais elle peut forcer les utilisateurs à se reconnecter s'ils se sont déjà authentifiés dans Chrome. Un autre problème est la confiance. Un WebView basique n'affiche pas l'URL ni l'icône de cadenas SSL, les utilisateurs doivent donc faire entièrement confiance à votre application pour ne pas les hameçonner. Google a même interdit l'utilisation de WebView pour les connexions Google OAuth en raison de risques potentiels de phishing. En termes de performances, les WebViews sont corrects, mais ils peuvent être plus lents ou plus gourmands en mémoire que l'utilisation du navigateur par défaut de l'utilisateur, en particulier lors du chargement de 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 le logo de l'application, etc., mais le contenu est rendu par Chrome dans un processus séparé. Pour les clés d'accès, les CCT présentent plusieurs avantages : ils partagent les cookies et les identifiants de l'utilisateur avec le navigateur Chrome, ce qui signifie que si l'utilisateur a enregistré une clé d'accès 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. Les performances sont souvent meilleures : Chrome peut être "préchauffé" en arrière-plan pour un chargement plus rapide. Et surtout, la sécurité est forte : parce que c'est essentiellement 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 poser 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 clés d'accès, car ils offrent un bon équilibre entre intégration et sécurité. En fait, ils sont analogues à SFSafariViewController/ASWebAuthSession d'iOS à bien des égards : ils s'appuient sur le navigateur par défaut pour l'authentification.

(Aparté : WKWebView vs SFSafariViewController d'Apple et WebView vs CCT d'Android ont de nombreux parallèles. SFSafariViewController et Chrome Tabs partagent 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 clés d'accès, partager l'état (cookies, magasins d'identifiants) est généralement souhaitable pour que la clé d'accès puisse être accessible et créée de manière fluide.)

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

Remarque sur les appareils gérés : Le comportement des clés d'accès change considérablement sur les appareils gérés où les stratégies de gestion des appareils mobiles (MDM) contrôlent le stockage des identifiants. Pour tester les clés d'accès sur des appareils gérés, voir Clés d'accès sur les appareils iOS et Android gérés.

Les flux Native et Embedded WebView requièrent des fichiers d'association pour établir une confiance cryptographique entre votre application et le domaine web. System WebView (ASWebAuthenticationSession) et Chrome Custom Tabs ne nécessitent pas d'association entre l'application et le site.

Le fichier AASA établit la connexion entre votre application iOS et votre domaine web, permettant aux clés d'accès de fonctionner sur les deux plateformes.

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

Exigences de configuration :

• Héberger sous /.well-known/apple-app-site-association sur votre domaine
• Servir sur HTTPS avec un certificat SSL valide
• Content-Type : application/json
• Pas de redirections sur le chemin .well-known
• Inclure 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 agressivement en cache les fichiers AASA (jusqu'à 24-48 heures) à l'aide d'un CDN, ce qui peut frustrer 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 le dernier fichier AASA directement depuis votre serveur

⚠️ Important : N'utilisez PAS ?mode=developer dans les versions de production. Ce paramètre est destiné uniquement au développement : son utilisation en production empêchera iOS de détecter correctement votre fichier AASA, ce qui cassera la fonctionnalité des clés d'accès.

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

Android utilise 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éberger sous /.well-known/assetlinks.json sur votre domaine
• Servir sur HTTPS avec un certificat valide
• Content-Type : application/json
• Inclure l'empreinte SHA256 de votre application (du 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 aux fonctionnalités des clés d'accès. Les exigences diffèrent légèrement selon votre approche d'implémentation.

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

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

L'implémentation Native et Embedded WebView nécessitent la capacité Associated Domains pour lier votre application à votre domaine web. System WebView (ASWebAuthenticationSession) n'en a pas besoin car il s'exécute dans le contexte de Safari.

Configuration dans Xcode :

1. Ouvrez votre projet dans Xcode
2. Sélectionnez la cible de votre application (app target)
3. Allez dans 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 requêtes d'origines liées (Related Origin Requests, ROR).

Les Embedded WebViews Android prennent en charge les clés d'accès via deux approches distinctes : la nouvelle approche basée sur WebKit (Section 5.3.1) et l'ancienne approche par pont JavaScript (Section 5.3.2). System WebView (Chrome Custom Tabs) ne nécessite aucune configuration : les identifiants fonctionnent automatiquement.

Android fournit des exemples officiels de WebView pour les clés d'accès illustrant les deux approches d'implémentation.

Intégration WebKit moderne avec gestion native des clés d'accès. Cette approche offre un support WebAuthn natif sans nécessiter de code de pont personnalisé.

Exemple officiel : Webkit WebView MainActivity

Exigences :

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

Implémentation :

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Check if Web Authentication is supported
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Enable Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Enable JavaScript
    webView.settings.javaScriptEnabled = true
}

Points clés :

• Pas besoin de pont JavaScript : WebAuthn fonctionne nativement dans WebView
• Détection de fonctionnalité requise : Vérifiez toujours WebViewFeature.WEB_AUTHENTICATION au moment de l'exécution
• Conditional UI non pris en charge : mediation:"conditional" (remplissage automatique de la clé d'accès dans les champs de saisie) ne fonctionne pas dans Embedded WebView
• Stratégie de repli : Si la fonctionnalité n'est pas disponible, utilisez Chrome Custom Tabs à la place

Notes sur les versions :

• Utilisez WebKit 1.12.1 ou plus récent (la 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 anciens APK sur l'appareil n'exposeront pas la fonctionnalité

Avant AndroidX WebKit 1.12.0, le support WebAuthn natif n'existait pas dans Embedded WebView. Cette ancienne approche utilise un pont Web-vers-Natif pour gérer les clés d'accès pour les appareils ne disposant pas du support WebAuthn natif de WebView.

Exemples officiels :

• PasskeyWebListener (Gestionnaire de Pont)
• Utilitaires d'encodage JavaScript

Quand l'utiliser : Pour prendre en charge les anciennes versions d'Android ou les appareils dotés d'anciennes implémentations de WebView.

Les équipes devaient soit :

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

Pour une implémentation détaillée, consultez le guide d'intégration du gestionnaire d'identifiants WebView d'Android. Cependant, nous recommandons fortement d'utiliser l'approche native WebKit 1.12.1+ pour les applications modernes.

Recommandation : Utilisez le support WebAuthn natif avec AndroidX WebKit 1.12.1+. S'il n'est pas disponible à l'exécution, repliez-vous sur les Chrome Custom Tabs qui offrent un excellent support des clés d'accès avec des identifiants partagés.

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

Pour les applications utilisant un seul domaine (ex : kayak.com), vous avez besoin de :

• Un fichier AASA pour iOS sur https://kayak.com/.well-known/apple-app-site-association
• Un fichier assetlinks.json pour Android sur https://kayak.com/.well-known/assetlinks.json
• Le droit Associated Domains configuré avec webcredentials:kayak.com

Les origines liées (Related Origins, ROR) sont une fonctionnalité WebAuthn qui permet à un seul ensemble de clés d'accès de fonctionner sur plusieurs domaines liés (ex : 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, et NON 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'applications (AASA/assetlinks) : Utilisés uniquement pour cartographier les applications à leurs sites web correspondants
• Embedded WebView iOS 18+ : Prend en charge ROR lorsqu'il est correctement configuré
• Droits Associated Domains : Incluent 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 Team ID et Bundle ID
• Être répertoriés dans les droits Associated Domains 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 leur 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, en contournant le cache CDN
• Si les fichiers ne sont pas accessibles via ces URL, la fonctionnalité de clé d'accès ne fonctionnera pas dans votre application
• Remplacez kayak.com ou kayak.de par votre/vos propre(s) domaine(s) 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 n'importe quel domaine peut casser la fonctionnalité de clé d'accès pour ce domaine.

Plus d'informations : Identifiant WebAuthn Relying Party dans les applications natives

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

L'organigramme suivant vous guide dans le choix de la bonne approche d'implémentation en fonction des besoins de votre application :

Référence rapide pour chaque voie :

• Connexion basée sur OAuth ? → System WebView (ASWebAuthenticationSession / Chrome Custom Tabs)
• Réutiliser l'authentification web dans une structure native ? → Embedded WebView avec configuration (WKWebView / Android WebView + WebKit 1.12.1+)
• Création d'abord native ? → Implémentation Native (AuthenticationServices / Credential Manager)
• Authentification web existante à réutiliser ? → System WebView pour une implémentation rapide ; sinon Native pour une UX optimale

Voici comment chaque approche se comporte selon des dimensions clés :

Explications des dimensions :

• Créer des clés d'accès : La facilité avec laquelle les utilisateurs peuvent créer des clés d'accès via cette approche
• Utiliser des clés d'accès : L'expérience d'authentification lors de l'utilisation de clés d'accès existantes
• Gérer des clés d'accès : Comment les utilisateurs voient, modifient ou suppriment les clés d'accès
• Complexité technique : L'effort de développement et la maintenance continue
• Support OAuth : La façon dont l'approche gère les flux d'authentification OAuth2/OIDC
• Temps d'installation : Le calendrier d'implémentation typique

Recommandé : System WebView

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

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

Exemple : Les applications de Voyage comme kayak.com et kayak.de utilisent OAuth pour l'authentification. System WebView leur permet de conserver leur infrastructure OAuth existante tout en ajoutant le support des clés d'accès via leurs pages d'authentification web.

Recommandé : Approche hybride

Utilisez System WebView pour l'authentification OAuth initiale, puis Embedded WebView pour les sessions post-authentification :

1. Authentification initiale : System WebView gère OAuth + la connexion par clé d'accès
2. Gestion de session : Basculez vers Embedded WebView pour le contenu web authentifié où un contrôle des cookies/sessions est requis
3. Configuration technique : Configurez les exigences de System et Embedded WebView ; pour Android, assurez-vous que AndroidX WebKit 1.12.1+ est inclus (voir Section 5)

Quand l'utiliser : Applications s'authentifiant via OAuth mais devant ensuite afficher un contenu web authentifié où une manipulation directe de la session est requise.

Recommandé : Implémentation Native

Vous créez à partir de zéro ou vous avez des écrans natifs ? Passez en 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 la superposition automatique de clés d'accès au démarrage de l'application - exclusive aux implémentations natives et offrant les taux de conversion les plus élevés
• Recommandation SDK : Utilisez les SDK Corbado (iOS, Android) pour accélérer le développement avec une gestion des cas particuliers testée en production

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

Recommandé : Migration par phases

Le diagramme suivant montre le chemin de migration incrémentiel :

Chaque phase s'appuie sur la précédente, permettant des améliorations incrémentielles sans perturber les utilisateurs existants.

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

Le test des clés d'accès dans les applications natives nécessite une approche structurée à plusieurs 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 de base : Inscription, authentification, flux multi-appareils, suppression de clé d'accès
• Couverture des plateformes : iOS (natif), Android (natif), navigateurs web sur toutes les versions d'OS
• Association de domaine : Vérifier que les fichiers AASA (iOS) et Digital Asset Links (Android) sont accessibles
• Flux d'annulation : Tester l'annulation par l'utilisateur aux invites du système d'exploitation et aux écrans biométriques
• Gestion des erreurs : Pannes du back-end, délais de connexion réseau, incohérences d'identifiants
• Cas particuliers : Verrouillage d'écran désactivé, iCloud/Google Password Manager désactivé
• Flux OAuth : Intégration complète OAuth + clés d'accès de bout en bout
• Appareils gérés : Environnements contrôlés par MDM (voir les tests sur appareils gérés)
• Gestionnaires tiers : Compatibilité 1Password, Bitwarden, Dashlane
• Authentification multi-appareils : Flux de codes QR et tests de transport hybride
• Spécifique à Embedded WebView : En cas d'utilisation d'Embedded WebView, vérifier la configuration WebKit 1.12.1+ sur Android
• Surveillance de production : Tableau de bord pour les taux de réussite, les échecs et la latence

Pour des conseils complets sur les tests, y compris les stratégies d'automatisation, les pièges spécifiques aux plateformes et une liste de contrôle pré-vol complète, consultez notre guide dédié : Tester les flux de clés d'accès dans les applications natives iOS et Android.

Envisagez d'inviter les utilisateurs à créer des clés d'accès après une connexion traditionnelle réussie (mot de passe, OAuth). Cette approche de conversion graduelle :

• Ne perturbe pas les flux d'authentification existants
• Permet une dégradation gracieuse si l'utilisateur refuse
• Augmente l'adoption des clés d'accès au fil du temps sans imposer de changements
• Fonctionne bien avec les trois approches d'implémentation

Exemple : Après la connexion OAuth via System WebView, affichez une invite native : "Activer une connexion plus rapide avec Face ID ?" Si accepté, créez la clé d'accès via la page web chargée dans System WebView.

Décider comment implémenter les clés d'accès - via l'Implémentation Native, System WebView ou Embedded WebView - 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 : System WebView (ASWebAuthenticationSession, Chrome Custom Tabs) est le point de départ recommandé. Il offre un excellent support OAuth, un effort d'implémentation minimal et un partage automatique des identifiants.

Pour les applications d'abord natives : Passez au natif le plus tôt possible. Une connexion native par clé d'accès offre l'UX la plus fluide avec des capacités exclusives telles que preferImmediatelyAvailableCredentials, qui permet la superposition automatique des clés d'accès au démarrage de l'application - chose que les implémentations WebView ne peuvent pas fournir. Avec iOS et Android fournissant désormais un support de première classe pour les clés d'accès, les succès réels démontrent une forte adoption. L'outillage (y compris les SDK open-source et les bibliothèques de plateformes) a mûri pour rendre l'intégration native réalisable dans des délais raisonnables. Bien que vous deviez garder à l'esprit les stratégies de gestion des appareils, la synchronisation multi-appareils et les fournisseurs tiers, ces défis peuvent être gérés avec une ingénierie et des tests minutieux. Le résultat est une connexion d'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 Embedded WebView : Embedded WebView est couramment utilisé dans deux scénarios réels. Premièrement, les applications basées sur OAuth utilisent souvent System WebView pour le flux de connexion initial, puis basculent vers Embedded WebView pour afficher les options de gestion des clés d'accès dans les écrans de paramètres où un contrôle de session est nécessaire - bien que certaines applications simplifient cela en conservant System WebView pour les deux flux. Deuxièmement, les applications qui intégraient déjà leur flux d'authentification dans des cadres WebView avant d'adopter les clés d'accès continuent ce modèle par souci de cohérence. Embedded WebView avec le support natif de WebAuthn (AndroidX WebKit 1.12.1+) nécessite une configuration (autorisations, droits, paramètres WebView) mais n'a plus besoin de code de pont JavaScript personnalisé. Notez que l'interface conditionnelle (Conditional UI) n'est pas prise en charge dans Embedded WebView. Choisissez cette approche lors de la maintenance de modèles d'authentification intégrés existants ou lorsque vous avez besoin d'un contrôle de session/cookies pour les écrans post-authentification.

En fin de compte, les clés d'accès dans les applications natives représentent un bond en avant considérable en matière de confort pour l'utilisateur et de sécurité. Qu'elles soient implémentées via Native, System WebView ou Embedded WebView, elles éliminent les risques de phishing et les fardeaux de gestion des mots de passe pour vos utilisateurs. Les implémentations du monde réel, comme l'intégration native des clés d'accès par VicRoads, démontrent que les approches d'abord natives offrent la plus forte adoption et satisfaction des utilisateurs lorsqu'elles sont correctement exécutées avec des fonctionnalités comme les superpositions automatiques de clés d'accès. 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 pour les nouvelles applications, System WebView pour les flux OAuth, ou Embedded WebView pour les modèles intégrés existants - vous pouvez offrir des connexions biométriques sans mot de passe qui concrétisent véritablement la vision des clés d'accès : une authentification simple, sûre et agréable pour tous.

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

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

• iOS : Capacité Associated Domains 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 de Chrome Custom Tabs (pas un simple WebView)
• iOS : Vérifier que les Domaines associés sont configurés si nécessaire
• Tester que les cookies/identifiants sont partagés avec le navigateur du système
• Vérifier que la page d'authentification web a une implémentation WebAuthn correcte

• iOS : Configuré avec les droits appropriés
• iOS : Les Domaines associés incluent tous les domaines pertinents
• iOS : Fichier AASA accessible et correctement formaté
• iOS : Tester 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 fonctionnalité à l'exécution pour WebViewFeature.WEB_AUTHENTICATION
• Android : setWebAuthenticationSupport() appelé avec WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android : JavaScript activé dans les paramètres 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é (non pris en charge dans Embedded WebView)
• Repli vers Chrome Custom Tabs si la fonctionnalité WebAuthn est indisponible

• Vérifier si l'utilisateur a un fournisseur d'identifiants non défini par défaut actif (1Password, Bitwarden, etc.)
• Vérifier que le fournisseur prend en charge les clés d'accès (tous les gestionnaires de mots de passe ne le font pas)
• Tester avec le gestionnaire d'identifiants natif de la plateforme (iCloud Keychain, Google Password Manager)

"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 (Android Embedded WebView)
• Vérifier : Configuration de Associated Domains, accessibilité du fichier AASA, version WebKit, détection de fonctionnalité, appel de setWebAuthenticationSupport()

Aucune invite de clé d'accès n'apparaît

• Pourrait signifier : AASA/assetlinks.json ne se charge pas, mauvais type de WebView, fichier AASA en cache
• Essayer : Valider les fichiers d'association, utiliser ?mode=developer sur iOS pour tester, vérifier le type de WebView

Pour un débogage détaillé, consultez notre article sur les Relying Party IDs dans les applications natives.

Un piège courant : les environnements de staging avec un accès restreint (liste blanche d'adresses IP, VPN uniquement) échoueront car les CDN d'Apple et de Google doivent pouvoir récupérer vos fichiers d'association.

• Les fichiers AASA/assetlinks sont accessibles publiquement (pas de liste blanche d'IP, pas d'exigence de VPN)
• Vérifiez que le CDN d'Apple peut atteindre votre fichier : https://app-site-association.cdn-apple.com/a/v1/votredomaine-staging.com?nocache=1
• Vérifiez que Google peut atteindre votre fichier : https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://votredomaine-staging.com&relation=delegate_permission/common.handle_all_urls

Sous-domaine de staging avec un rpID de production :

Si votre environnement de staging (ex : stg.login.example.com) utilise le domaine de production comme rpID (ex : example.com), la recherche AASA se produit sur le domaine rpID, pas sur votre sous-domaine de staging. Cela signifie que :

• Ajoutez les ID de bundle des applications de staging à votre fichier AASA de production
• Soyez conscient que les clés d'accès créées en staging apparaîtront dans les flux de connexion en production (confusion potentielle)

Exemple (plusieurs environnements partageant un seul AASA) :

{
    "webcredentials": {
        "apps": [
            "TEAMID123.com.example.app",
            "TEAMID123.com.example.app.dev",
            "TEAMID123.com.example.app.stg",
            "TEAMID123.com.example.app.pre"
        ]
    }
}

Recommandation : Utilisez un rpID de staging distinct correspondant à votre domaine de staging pour éviter le chevauchement d'identifiants entre les environnements. Cela nécessite des fichiers AASA publiquement accessibles sur le domaine de staging.

Clarification sur ?mode=developer :

Le paramètre ?mode=developer dans les Domaines associés contourne le cache CDN d'Apple mais ne contourne pas l'exigence d'accessibilité. Votre fichier AASA doit toujours être accessible depuis l'appareil (pas par le biais du CDN d'Apple, mais directement). Cela aide pendant le développement lors des itérations sur les modifications AASA, mais n'aidera pas si votre serveur de staging est sur liste blanche IP.

SDK Natifs Corbado :

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

Documentation des plateformes :

• Apple : Support des clés d'accès
• Google : Credential Manager

Outils de validation :

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

À 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 →

Le choix dépend de votre architecture d'authentification. Si votre application utilise OAuth2 ou OIDC, System WebView (ASWebAuthenticationSession sur iOS ou Chrome Custom Tabs sur Android) nécessite le moins d'efforts d'implémentation et aucune configuration de fichier d'association. Pour les nouvelles applications d'abord natives, l'implémentation Native offre une expérience utilisateur supérieure, tandis qu'Embedded WebView convient aux applications qui intègrent déjà l'authentification dans un cadre WebView et qui ont besoin de contrôler la session ou les cookies après la connexion.

SFSafariViewController exploite le moteur de Safari, affiche la barre d'URL avec des indicateurs SSL et offre une protection contre le phishing, ce qui le rend plus fiable pour les flux d'authentification. WKWebView offre plus de personnalisation de l'interface utilisateur, mais dispose d'un magasin de cookies isolé distinct de Safari, requiert des droits de Domaines associés et un fichier AASA pour activer les clés d'accès, et n'affiche pas la barre d'URL, ce qui réduit les signaux de confiance des utilisateurs.

Les Chrome Custom Tabs partagent les cookies et les identifiants enregistrés avec le navigateur Chrome de l'utilisateur, ce qui signifie que les clés d'accès enregistrées dans Google Password Manager sont accessibles pendant l'authentification. Le WebView Android standard dispose d'un magasin de cookies isolé, n'affiche pas l'URL ni les indicateurs SSL, et Google l'a explicitement interdit pour les connexions aux comptes Google en raison de risques de phishing.

Si un utilisateur a un gestionnaire d'identifiants tiers tel que 1Password défini comme fournisseur actif, il interceptera souvent la création et le stockage des clés d'accès, prenant la priorité sur le gestionnaire d'identifiants natif de la plateforme (Trousseau iCloud ou Google Password Manager). Cela signifie que les clés d'accès peuvent être stockées dans l'application tierce plutôt que dans le trousseau de la plateforme, ce qui affecte la synchronisation multi-appareils et le comportement de gestion des clés d'accès.

Lorsque les stratégies MDM désactivent la synchronisation des identifiants, les clés d'accès deviennent liées à l'appareil et ne peuvent pas être transférées vers un appareil de remplacement, contrairement aux scénarios grand public typiques. Les applications ciblant les environnements d'entreprise doivent prévoir des mécanismes d'authentification de secours tels que le mot de passe ou la connexion par lien magique pour gérer les cas où un utilisateur reçoit un nouvel appareil géré.