--- url: 'https://www.corbado.com/fr/blog/applications-natives-passkeys' title: 'Clés d''accès pour applications natives : Implémentation native vs WebView' description: 'Cet article explique comment implémenter les clés d''accès dans les applications natives iOS et Android. Découvrez quand utiliser une implémentation native ou WebView.' lang: 'fr' author: 'Vincent Delitz' date: '2025-06-20T15:09:01.430Z' lastModified: '2026-07-04T06:04:30.646Z' keywords: 'webview, application native, application native ios, application native android, CCT, chrome custom tab, wkwebview, sfsafariviewcontroller, sfauthenticationsession, aswebauthenticationsession' category: 'WebAuthn Know-How' --- # Clés d'accès pour applications natives : Implémentation native vs WebView ### Implémentation des clés d'accès dans les applications natives : Référence rapide | **Approche** | **Adoption** | **Création de clés d'accès** | **Utilisation de clés d'accès** | **Gestion des clés d'accès** | **Complexité technique** | **Support OAuth** | | :------------------------ | :----------: | :--------------------------------------------- | :------------------------------------------------------------------ | :------------------------------ | :----------------------- | :----------------------- | | **Implémentation Native** | 🟢🟢🟢 | Forte adoption, meilleure UX, biométrie fluide | Authentification instantanée et silencieuse | Contrôle natif total | Moyenne à Élevée | Nécessite un flux séparé | | **System WebView** | 🟢🟢 | Bonne adoption, expérience de type navigateur | UX de navigateur standard, trousseau partagé | Gestion basée sur le navigateur | Faible | Excellent | | **Embedded WebView** | 🟢 | Adoption plus faible, configuration requise | Support natif iOS & Android (WebKit 1.12.1+), pas de Conditional UI | Contrôle limité | Moyenne à Élevée | N/A | **Remarque :** System [WebView](https://www.corbado.com/blog/native-app-passkeys) et Embedded [WebView](https://www.corbado.com/blog/native-app-passkeys) sont souvent combinés, System [WebView](https://www.corbado.com/blog/native-app-passkeys) gérant la [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) (avec partage automatique des identifiants), puis Embedded WebView affichant la gestion des [clés d'accès](https://www.corbado.com/fr/glossary/cda) 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) WebView avec WebKit 1.12.1+) - **Création d'une application prioritairement native ?** → [Implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) Native (Apple AuthenticationServices, Google Credential Manager) ## Key Facts - **preferImmediatelyAvailableCredentials** active une superposition automatique de clé d'accès immédiatement au lancement de l'application, exclusive à l'implémentation Native et indisponible dans les variantes WebView. - **System WebView** (ASWebAuthenticationSession sur iOS, Chrome Custom Tabs sur Android) est l'approche recommandée pour la connexion basée sur OAuth, nécessitant un code natif minimal et aucun fichier d'association. - **Android Embedded WebView** nécessite AndroidX WebKit 1.12.1+ avec détection de fonctionnalité à l'exécution ; l'interface conditionnelle (Conditional UI, remplissage automatique des clés d'accès dans les champs de saisie) n'est pas prise en charge avec cette approche. - **Fichiers d'association well-known** (AASA pour iOS, assetlinks.json pour Android) sont requis pour les implémentations Native et Embedded WebView, mais pas pour System WebView. ## 1. Choix d'implémentation des clés d'accès dans les applications natives Les plateformes mobiles modernes offrent trois approches distinctes pour intégrer les [clés d'accès](https://www.corbado.com/fr/glossary/cda) 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](https://www.corbado.com/fr/glossary/cda) directement dans votre application à l'aide des API de la plateforme (iOS AuthenticationServices, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Manager). Offre la meilleure expérience utilisateur avec une [authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) biométrique fluide, mais nécessite un effort technique d'[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) moyen à élevé. 2. **System WebView** : Utilisez le composant navigateur de la plateforme (**iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs**) pour gérer l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys). Excellent pour les flux de [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) basés sur OAuth et partage les identifiants avec le navigateur du système. 3. **Embedded WebView** : Intégrez une [vue](https://www.corbado.com/blog/vuejs-passkeys) web personnalisable (**iOS WKWebView, Android WebView**) au sein de votre application pour réutiliser l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) 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](https://www.corbado.com/blog/vuejs-passkeys) 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. ### 1.1 Implémentation Native : La meilleure expérience utilisateur Une [implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) 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](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) 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](https://docs.corbado.com/passkey-ui-flows/native/passkey-login/overlay) 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) Kotlin) **Avantage clé : preferImmediatelyAvailableCredentials()** Les implémentations natives peuvent exploiter `preferImmediatelyAvailableCredentials()` pour créer une [superposition automatique de clés d'accès](https://docs.corbado.com/passkey-ui-flows/native/passkey-login/overlay) 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](https://www.corbado.com/glossary/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. #### 1.1.1 Clés d'accès natives sur iOS (Swift) L'implémentation native des clés d'accès sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) implique le framework **AuthenticationServices** d'[Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android), 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](https://www.corbado.com/fr/blog/meilleures-pratiques-connexion-passkey) 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](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) 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 #### 1.1.2 Clés d'accès natives sur Android (Kotlin) L'implémentation native des clés d'accès sur Android utilise l'API **Credential Manager** (ou l'ancienne API [FIDO2](https://www.corbado.com/glossary/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](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) - Deux modes d'interface principaux : - **Connexion par champ de texte** : Champ de nom d'utilisateur traditionnel avec la [connexion par clé d'accès](https://www.corbado.com/fr/blog/meilleures-pratiques-connexion-passkey) 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) dans les [applications natives](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) (bien que le [Conditional UI](https://www.corbado.com/glossary/conditional-ui) fonctionne dans les applications web) #### 1.1.3 Défis d'implémentation & Solutions 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](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) 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](https://www.corbado.com/glossary/icloud-keychain) ou [Google Password Manager](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/fr/blog/cles-dacces-brave-browser) comme [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) 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. #### 1.1.4 Simplification avec les SDK Natifs 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](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) dans des simulateurs). **Recommandation :** Pour les implémentations natives, nous recommandons d'utiliser les SDK Corbado ([iOS Swift Passkey SDK](https://github.com/corbado/corbado-ios), [Android Kotlin Passkey SDK](https://github.com/corbado/corbado-android)) 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. ### 1.2 Implémentation System WebView : Authentification compatible OAuth 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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/fr/glossary/authentification-unique-sso) à 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](https://www.corbado.com/fr/blog/violations-donnees-japon) comme Google et GitHub ont adopté cette approche pour ajouter la [connexion par clé d'accès](https://www.corbado.com/fr/blog/meilleures-pratiques-connexion-passkey) à 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. #### 1.2.1 Options System WebView sur iOS 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](https://www.corbado.com/blog/native-app-passkeys) lorsque le partage de session Safari est requis - Moins personnalisable mais plus digne de confiance pour les utilisateurs | Fonctionnalité | ASWebAuthenticationSession | SFSafariViewController | | :------------------------------ | :------------------------- | :---------------------- | | **Cas d'utilisation principal** | Flux d'authentification | Navigation web générale | | **OAuth/OIDC** | Excellent | Bon | | **Support Clés d'accès** | Oui | Oui | | **Personnalisation** | Limitée | Minimale | **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. #### 1.2.2 System WebView Android : Chrome Custom Tabs 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](https://www.corbado.com/blog/native-app-passkeys) d'iOS, offrant un excellent support OAuth tout en conservant l'accès aux clés d'accès stockées. ### 1.3 Implémentation Embedded WebView : Contrôle de session avec configuration supplémentaire 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](https://www.corbado.com/blog/vuejs-passkeys) 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](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) de fonctionnalité à l'exécution - Acceptation de la limitation de [Conditional UI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkeys-in-app-browsers) (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](https://www.corbado.com/fr/blog/webauthn-conditional-ui-remplissage-automatique-passkeys) 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) ## 2. Vue d'ensemble des options WebView 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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/fr/glossary/authentification-unique-sso) (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. ## 3. WebViews sous iOS 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](https://apps.apple.com/de/app/webview-wkwebview-and-uiwebview-rendering/id928647773). ### 3.1 WKWebView ![Passkeys WKWebView](https://www.corbado.com/website-assets/6523ba7b664086bd796e4329_ios_wkwebview_example_24707076e0.PNG) **WKWebView** est un composant WebView polyvalent pour iOS. Les [développeurs](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) peuvent intégrer un [WKWebView](https://www.corbado.com/blog/native-app-passkeys) pour rendre du contenu web avec un haut degré de contrôle sur l'interface utilisateur et le comportement. [WKWebView](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/glossary/phishing)). Certaines applications ont même abusé de WKWebView pour injecter des scripts ou modifier du contenu (ex : [TikTok](https://www.corbado.com/blog/tiktok-passkeys) 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. ### 3.2 SFSafariViewController ![Passkeys SFSafariViewController](https://www.corbado.com/website-assets/6523ba92021afcb2b832569b_ios_sfsafariviewcontroller_example_4638988ed0.PNG) **SFSafariViewController** offre une expérience Safari intégrée à l'application. Lorsque vous ouvrez une URL avec [SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys), 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](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) pour votre site, Safari peut la trouver et même afficher la saisie automatique de l'interface conditionnelle pour une connexion facile. [SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys) 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. ![iOS webviews](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/i_OS_webviews_fe6e593538.jpg) | | WKWebView | SFSafariViewController | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Expérience utilisateur | - **Sensation native :** Les utilisateurs peuvent avoir l'impression que le contenu web fait partie intégrante de l'application car les développeurs peuvent personnaliser l'apparence pour qu'elle corresponde au design de l'application.
- **Remplissage automatique :** Le remplissage automatique avec les données de Safari est possible | - **Fluide :** Expérience utilisateur fluide en utilisant les paramètres Safari de l'utilisateur assurant une navigation web cohérente entre l'application native et le navigateur. | | Expérience développeur | - **Hautement personnalisable :** Vastes possibilités de personnalisation et de configuration disponibles
- **Flexible :** De nombreuses API pour interagir avec le contenu web | - **Moyennement personnalisable :** Options de personnalisation limitées, surtout par rapport à WKWebView,
- **Simple :** Plus simple à implémenter par rapport à WKWebView | | Performance | - **Plutôt lent :** Selon l'implémentation et le contenu web, les vitesses de chargement peuvent être optimisées, mais pourraient rester plus lentes que SFSafariViewController en raison du traitement supplémentaire des fonctionnalités personnalisées et des interactions. | - **Plutôt rapide :** Offre généralement de meilleures performances car il exploite le moteur Safari, optimisé pour la vitesse et l'efficacité, offrant des temps de chargement rapides pour les pages web. | | Confiance et reconnaissance | - **Affichage de l'URL non requis :** WKWebView n'affiche souvent pas l'URL, rendant plus difficile pour les utilisateurs de vérifier la page web. Potentiel pour les applications malveillantes d'imiter ce comportement et d'hameçonner les identifiants. | - **Expérience type navigateur :** Rendu des pages web en utilisant Safari, offrant une expérience "type navigateur". Les utilisateurs peuvent voir l'URL et accéder aux fonctionnalités de remplissage automatique de Safari, instaurant potentiellement plus de confiance grâce à l'interface familière. | | Isolation | - **Séparé :** Les cookies et les sessions sont séparés de Safari ; les utilisateurs ne seront pas automatiquement connectés dans un WKWebView. | - **Séparé :** Les cookies et les sessions sont séparés de Safari ; les utilisateurs ne seront pas non plus automatiquement connectés à SFSafariViewController. | | Vulnérabilités | - **Sécurisé :** Intrinsèquement sécurisé grâce au sandboxing de l'application par Apple, mais le comportement et la sécurité dépendent de l'implémentation de l'application. Vulnérabilités potentielles si non implémenté correctement. | - **Plus sécurisé :** Bénéficie des fonctionnalités de sécurité intégrées à Safari, incluant les avertissements anti-phishing et contre les sites web malveillants. Généralement considéré comme plus sûr pour afficher du contenu web que WKWebView grâce à ces fonctionnalités et à la familiarité de l'utilisateur avec Safari. | | Autre | - **Fonctionnalités non disponibles :** Certaines fonctionnalités du navigateur (ex : WebAuthn) peuvent ne pas être totalement accessibles en raison de préoccupations de sécurité et du fait que WKWebView s'exécute dans le contexte de l'application.
- **Injection JavaScript :** Certaines applications (ex : TikTok) injectent du JavaScript de suivi, ou restreignent le contrôle utilisateur (ex : Facebook)
- **Problèmes de confidentialité :** Plus de [retours de la communauté](https://gist.github.com/chrmod/a5c71f9e7f86782d47eb1734df440260) concernant la confidentialité | - **Pas d'injection JavaScript :** N'autorise pas l'exécution de JavaScript depuis l'application, renforçant la sécurité et la confidentialité. Il ne prend pas non plus en charge les alertes ou confirmations JavaScript, ce qui peut affecter l'expérience utilisateur sur certaines pages web.
- Mode Lecteur : Fournit un mode lecteur pour une version épurée et facile à lire des articles. | ### 3.3 SFAuthenticationSession / ASWebAuthenticationSession **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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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. ## 4. WebViews sous Android 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](https://play.google.com/store/apps/details?id=com.ansbilisim.webviewvscustomchrometabs&hl=en_US). ### 4.1 Android WebView ![Passkeys Android WebView](https://www.corbado.com/website-assets/6523ba9e959c16f8fec2e8c8_android_webview_example_0cd6d26c55.jpg) **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](https://www.corbado.com/glossary/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. ### 4.2 Chrome Custom Tabs (CCT) ![Passkeys Chrome Custom Tabs (CCT)](https://www.corbado.com/website-assets/6523baa76223bf541db3ed47_android_chrome_custom_tab_example_2c9fa9233b.jpg) 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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/passkeys-vs-password-managers)), 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](https://www.corbado.com/blog/native-app-passkeys) 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.) ![android webviews](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_webviews_b411ad674d.jpg) | Fonctionnalité | WebView | Chrome Custom Tab | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Expérience utilisateur** | - **Flexibilité :** Fournit un riche ensemble d'API pour interagir avec le contenu web et gérer les interactions de l'utilisateur, y compris la gestion des boîtes de dialogue JavaScript et des demandes d'autorisation.
- **Cohérence :** Maintenir une UX cohérente, surtout avec des contenus web variés, peut être un défi. | - **Fonctionnalités du navigateur :** Partage des fonctionnalités telles que l'économiseur de données et la saisie automatique synchronisée sur tous les appareils.
- **Bouton de retour :** Permet aux utilisateurs de revenir facilement à l'application avec un bouton de retour intégré.
- **Dépendance :** Repose sur l'application Chrome, qui peut ne pas être disponible ou mise à jour sur tous les appareils des utilisateurs.
- **Redirection vers le navigateur :** Certaines fonctionnalités peuvent rediriger les utilisateurs vers l'application Chrome, perturbant potentiellement l'expérience utilisateur.
- **Custom Tabs Partiels :** Seule une portion de l'écran peut être utilisée pour le Chrome Custom Tab tandis que le reste montre l'application native. | | **Expérience développeur** | - **Hautement personnalisable :** Offre de vastes options/besoins de personnalisation.
- **Interactivité :** Fournit de nombreuses API pour interagir avec le contenu web et gérer les interactions utilisateur. | - **Personnalisable :** Permet la personnalisation de la couleur de la barre d'outils, du bouton d'action, de la barre d'outils inférieure, des éléments de menu personnalisés et des animations d'entrée/sortie.
- **Rappel (Callback) :** Délivre un rappel à l'application lors d'une navigation externe.
- **Fonctionnalités de sécurité :** Fournit des fonctionnalités prêtes à l'emploi, éliminant le besoin de gérer les demandes, l'octroi d'autorisations ou les magasins de cookies. | | **Performance** | - **Performance médiocre :** Peut ne pas offrir le même niveau de performance que les Chrome Custom Tabs (CCT). | - **Préchauffage :** Inclut le préchauffage du navigateur en arrière-plan et le chargement spéculatif des URL pour améliorer le temps de chargement des pages.
- **Priorité :** Empêche les applications lançant un Custom Tab d'être évincées pendant son utilisation en élevant son importance au niveau "premier plan". | | **Confiance et reconnaissance** | - **URL & SSL non visibles :** Les informations URL et SSL ne sont pas visiblement inhérentes à un WebView. À moins que le développeur de l'application n'implémente ces fonctionnalités, les utilisateurs ne sauront pas s'ils sont sur le bon site web ou sur un site de phishing. | - **URL & SSL visibles :** Utilise le véritable navigateur Chrome pour rendre les pages. Les utilisateurs peuvent voir l'URL et le certificat SSL (indiquant si la connexion est sécurisée). Cela peut donner aux utilisateurs l'assurance qu'ils ne sont pas sur un site de phishing. | | **Isolation** | - **S'exécute dans le processus de l'application :** Si une application présente une vulnérabilité permettant l'exécution de code malveillant, il y a un risque que le WebView puisse être compromis. Cependant, WebView reçoit également des mises à jour, mais son comportement et sa sécurité peuvent être plus dépendants de l'application qui l'utilise.
- **Pas de partage de cookies / session :** Ne partage pas les cookies ou les sessions avec le navigateur principal de l'appareil, offrant une isolation mais obligeant potentiellement les utilisateurs à se reconnecter. | - **S'exécute dans le processus de Chrome :** Faisant partie de Chrome, les Custom Tabs s'exécutent dans le même processus et bénéficient des mêmes mises à jour et fonctionnalités de sécurité que Chrome.
- **Magasin de cookies partagé et modèle de permissions :** Assure que les utilisateurs n'ont pas à se reconnecter aux sites ou à ré-accorder des autorisations.
- **Paramètres & Préférences Chrome :** Utilise les paramètres et les préférences de Chrome. | | **Vulnérabilités** | - **Rappels pour voler des identifiants :** Les vulnérabilités potentielles incluent le fait que parfois le JavaScript est requis, ce qui ouvre la porte à d'autres applications pour exécuter du code malveillant, tel que [l'enregistrement de rappels essayant d'intercepter les noms d'utilisateur et les mots de passe.](https://arstechnica.com/gadgets/2021/07/google-boots-google-play-apps-for-stealing-users-facebook-passwords/)
- **Phishing :** De plus, une application malveillante pourrait ouvrir une autre page web imitant le flux de lien lors d'une tentative de phishing. | - **Google Safe Browsing :** Emploie la navigation sécurisée de Google pour protéger à la fois l'utilisateur et l'appareil des sites dangereux.
- **Décoration de navigateur sécurisée :** S'assure que l'utilisateur voit toujours l'URL exacte avec laquelle il interagit et peut consulter les informations du certificat du site web, réduisant ainsi le risque de phishing. De plus, les Custom Tabs n'autorisent pas l'injection de JavaScript. | | **Autre** | - **Google a banni les WebViews** pour la connexion des utilisateurs aux comptes Google. | | ## 5. Exigences de configuration technique 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. ### 5.1 Fichiers d'association well-known (Native et Embedded) 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. #### 5.1.1 iOS : Fichier Apple-App-Site-Association (AASA) ![ios app native passkeys association](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/ios_app_native_passkeys_association_7dec89b433.png) 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** : ```json { "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](https://developer.apple.com/account/ios/identifier/bundle) pour vérifier votre configuration. #### 5.1.2 Android : Digital Asset Links (assetlinks.json) ![android app native passkeys association](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_app_native_passkeys_association_1be4600a63.png) 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** : ```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](https://developers.google.com/digital-asset-links/tools/generator) pour créer et vérifier votre configuration. ### 5.2 Configuration des droits iOS 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. #### 5.2.1 Comprendre Runner.entitlements / VotreApp.entitlements Le fichier des droits (souvent nommé `Runner.entitlements` dans les applications [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) 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](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) associés (Associated Domains). **Emplacement du fichier** : Généralement dans votre projet Xcode sous `ios/Runner/Runner.entitlements` #### 5.2.2 Capacité Associated Domains 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 com.apple.developer.associated-domains webcredentials:votredomaine.com webcredentials:sousdomaine.votredomaine.com ``` #### 5.2.3 Exigences par approche | Approche | Domaines associés requis | Configuration supplémentaire | | :------------------------ | :----------------------- | :------------------------------------------------- | | **Implémentation Native** | Oui | Implémentation dédiée | | **System WebView** | Non requis | La configuration web par défaut fonctionne | | **Embedded WebView** | Oui | Nécessite la configuration AndroidX WebKit 1.12.1+ | **Domaines multiples** : Si votre application doit fonctionner avec plusieurs [domaines](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys), vous pourriez avoir besoin des requêtes d'[origines liées](https://www.corbado.com/fr/blog/webauthn-origines-liees-passkeys-inter-domaines) (Related Origin Requests, [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys)). ### 5.3 Configuration de WebView Android (Embedded WebView uniquement) 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](https://github.com/android/identity-samples/tree/main/WebView) illustrant les deux approches d'implémentation. #### 5.3.1 Support WebAuthn natif (WebKit 1.12.1+, Recommandé) 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](https://github.com/android/identity-samples/blob/0f79816496df1897343b64aa31a4ba4ac3f85021/WebView/WebkitWebView/app/src/main/java/com/google/webkit/webviewsample/MainActivity.kt) **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](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) 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** : ```kotlin 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é #### 5.3.2 Ancienne approche : Pont JavaScript (Pré-WebKit 1.12.0) 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)](https://github.com/android/identity-samples/blob/0f79816496df1897343b64aa31a4ba4ac3f85021/WebView/CredentialManagerWebView/PasskeyWebListener.kt) - [Utilitaires d'encodage JavaScript](https://github.com/android/identity-samples/blob/0f79816496df1897343b64aa31a4ba4ac3f85021/WebView/CredentialManagerWebView/javascript/encode.js) **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](https://developer.android.com/training/sign-in/credential-manager-webview). 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. ### 5.4 Origines, Origines liées (ROR) et Vérification des fichiers well-known Lors de l'implémentation des clés d'accès dans des [applications natives](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys), vous devez établir la confiance entre votre application et votre/vos domaine(s) web. Cette section explique comment gérer des [domaines](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) uniques, des domaines liés multiples (ROR) et comment vérifier que vos fichiers d'association well-known sont correctement configurés. #### 5.4.1 Configuration de domaine unique 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](https://kayak.com/.well-known/apple-app-site-association) - Un fichier assetlinks.json pour Android sur [https://kayak.com/.well-known/assetlinks.json](https://kayak.com/.well-known/assetlinks.json) - Le droit Associated Domains configuré avec `webcredentials:kayak.com` #### 5.4.2 Origines liées (ROR) pour les domaines multiples Les [origines liées](https://www.corbado.com/fr/blog/webauthn-origines-liees-passkeys-inter-domaines) (Related Origins, [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys)) 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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) utilise le point de terminaison `/.well-known/webauthn` sur chaque site pour définir les [origines liées](https://www.corbado.com/fr/blog/webauthn-origines-liees-passkeys-inter-domaines), 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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+ : 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 #### 5.4.3 Vérification des fichiers well-known 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 : | Domaine | Vérification AASA d'Apple | Vérification Digital Asset Links de Google | | :-------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kayak.com | [Tester le fichier AASA](https://app-site-association.cdn-apple.com/a/v1/kayak.com?nocache=1)
Vérifier si le CDN d'Apple peut récupérer votre fichier | [Tester assetlinks.json](https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://www.kayak.com&relation=delegate_permission/common.handle_all_urls)
Vérifier que Google peut accéder à vos asset links | | kayak.de | [Tester le fichier AASA](https://app-site-association.cdn-apple.com/a/v1/kayak.de?nocache=1)
Vérifier si le CDN d'Apple peut récupérer votre fichier | [Tester assetlinks.json](https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://www.kayak.de&relation=delegate_permission/common.handle_all_urls)
Vérifier que Google peut accéder à vos asset links | **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](https://www.corbado.com/glossary/relying-party) dans les [applications natives](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) ## 6. Recommandations pour l'implémentation des clés d'accès 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. ### 6.1 Arbre de décision 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 ### 6.2 Comparaison des approches : Dimensions d'adoption Voici comment chaque approche se comporte selon des dimensions clés : | Approche | Créer des clés d'accès | Utiliser des clés d'accès | Gérer des clés d'accès | Complexité technique | Support OAuth | Temps d'installation | | :------------------------ | :------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------- | :------------------------------------------------ | :---------------------------- | | **Implémentation Native** | **Forte adoption**
Biométrie fluide, meilleure UX | **Instantané, silencieux**
`preferImmediatelyAvailableCredentials` active la superposition automatique au démarrage | **Contrôle natif total**
Intégration aux paramètres | Moyenne-Élevée
API spécifiques à la plateforme | Nécessite l'implémentation d'un flux OAuth séparé | Des semaines à des mois | | **System WebView** | **Bonne adoption**
Expérience navigateur familière | **UX de navigateur standard**
Conditional UI dans les champs de saisie, trousseau partagé | **Basé sur le navigateur**
Gestion via navigateur | **Faible**
Code natif minimal | **Excellent**
Conçu pour OAuth | Quelques jours à des semaines | | **Embedded WebView** | **Adoption plus faible**
Nécessite une configuration | **Support WebAuthn natif**
WebKit 1.12.1+, pas de Conditional UI | **Contrôle limité**
Pas d'intégration native | **Moyenne-Élevée**
Config WebView + droits | Nécessite une configuration | 1-2 semaines | **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 ### 6.3 Recommandations spécifiques par scénario #### 6.3.1 Scénario A : Authentification basée sur OAuth (Le plus courant) **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](https://www.corbado.com/passkeys-for-travel) comme [kayak](https://www.corbado.com/blog/kayak-passkeys).com et [kayak](https://www.corbado.com/blog/kayak-passkeys).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. #### 6.3.2 Scénario B : Connexion native avec besoins de contrôle de session **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. #### 6.3.3 Scénario C : Nouvelle application native ou prioritairement native **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](https://docs.corbado.com/passkey-ui-flows/native/passkey-login/overlay) - 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. #### 6.3.4 Scénario D : Application existante avec connexion web **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. ### 6.4 Exigences techniques clés par approche | Exigence | Native | System WebView | Embedded WebView | | :---------------------------------------- | :--------------------------- | :--------------------------- | :--------------------------- | | **Fichiers well-known (AASA/assetlinks)** | Requis | Non requis | Requis | | **Domaines associés iOS** | Requis | Non requis | Requis | | **Bibliothèque Android WebKit** | Sans objet | Non requis | **Requis** (1.12.1+) | | **Identifiant (RP ID)** | Doit correspondre au domaine | Doit correspondre au domaine | Doit correspondre au domaine | Voir la Section 5 pour des instructions de configuration détaillées. ### 6.5 Recommandations de test 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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis), [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024), [Dashlane](https://www.corbado.com/blog/dashlane-passkeys) - [ ] **Authentification multi-appareils** : Flux de codes QR et tests de [transport hybride](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) - [ ] **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. ### 6.6 Stratégie d'inscription opportuniste 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](https://www.corbado.com/fr/blog/analyse-rentabilite-adoption-passkeys) 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](https://www.corbado.com/faq/is-face-id-passkey) ?" Si accepté, créez la clé d'accès via la page web chargée dans System WebView. ## 7. Conclusion 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](https://docs.corbado.com/passkey-ui-flows/native/passkey-login/overlay) - 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/vicroads-passkeys), 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](https://www.corbado.com/fr/blog/comment-passer-totalement-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. ## 8. Liste de contrôle de dépannage 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 : ### Toutes les approches : Problèmes de fichiers d'association - [ ] 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](https://www.corbado.com/glossary/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\://) ### Implémentation Native - [ ] 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 ### System WebView - [ ] 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 ### Embedded WebView - [ ] 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](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) 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 ### Problèmes de fournisseurs tiers - [ ] Vérifier si l'utilisateur a un fournisseur d'identifiants non défini par défaut actif (1Password, [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024), 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](https://www.corbado.com/blog/how-to-use-google-password-manager)) ### Messages d'erreur courants **"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](https://www.corbado.com/glossary/relying-party) IDs dans les applications natives. ### Problèmes liés à l'environnement de développement et de staging 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) :** ```json { "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. ## 9. Ressources **SDK Natifs Corbado :** - [SDK iOS (Swift)](https://github.com/corbado/corbado-ios) - [SDK Android (Kotlin)](https://github.com/corbado/corbado-android) - [Package Flutter](https://pub.dev/packages/passkeys) **Documentation des plateformes :** - [Apple : Support des clés d'accès](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys) - [Google : Credential Manager](https://developer.android.com/training/sign-in/passkeys) **Outils de validation :** - [Validateur AASA d'Apple](https://developer.apple.com/account/ios/identifier/bundle) - [Générateur de Digital Asset Links de Google](https://developers.google.com/digital-asset-links/tools/generator) ## Foire aux questions ### Comment choisir entre Native, System WebView et Embedded WebView pour les clés d'accès dans mon application mobile ? 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. ### Quelle est la différence entre WKWebView et SFSafariViewController pour l'authentification par clé d'accès iOS ? 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. ### Pourquoi devrais-je utiliser les Chrome Custom Tabs plutôt qu'Android WebView pour les flux de clés d'accès ? 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. ### Comment les gestionnaires d'identifiants tiers comme 1Password affectent-ils la création de clés d'accès natives sur iOS et Android ? Si un utilisateur a un gestionnaire d'identifiants tiers tel que [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) 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. ### Que se passe-t-il avec les clés d'accès sur les appareils d'entreprise gérés où la synchronisation du trousseau iCloud ou de Google Password Manager est désactivée par stratégie ? 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](https://www.corbado.com/fr/blog/comment-activer-passkeys-android) ou la connexion par lien magique pour gérer les cas où un utilisateur reçoit un nouvel appareil géré.