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

Cet article explique comment implémenter les passkeys dans les applications natives (iOS + Android). Vous y apprendrez quel type de WebView est recommandé pour l'authentification par passkey.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Choix d'implémentation des passkeys dans les applications natives#

L'authentification agit comme une sentinelle, protégeant les données des utilisateurs et garantissant des interactions sécurisées au sein des applications natives. L'avènement des passkeys a révolutionné ce domaine, offrant un mécanisme d'authentification robuste et convivial. Il existe deux manières principales d'intégrer les passkeys dans une application native : soit via une implémentation native, soit via une WebView. Examinons d'abord comment ces deux méthodes se comparent.

1.1 Implémentation native : excellente expérience utilisateur#

Une implémentation native est souvent considérée comme offrant la meilleure expérience utilisateur au sein d'une application. Elle se caractérise par ses interactions utilisateur fluides, intégrées et cohérentes, adaptées précisément à l'environnement du système d'exploitation, que ce soit iOS ou Android. L'exigence pour une implémentation 100 % native est de passer au 100 % sans mot de passe et d'être véritablement natif en matière de passkeys. Cette approche vous libère des frictions potentielles liées à la transition entre l'application native et le contenu web (affiché via une WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Implémentation WebView : expérience de type navigateur#

Lors du développement d'une application native, la voie du tout natif n'est pas toujours possible. Dans les scénarios où vous devez encore prendre en charge l'authentification par mot de passe utilisant OAuth2, une intégration entièrement native peut ne pas être réalisable, faisant des implémentations WebView la seule alternative viable. La WebView agit comme un pont, intégrant le contenu web directement dans votre application, offrant une expérience utilisateur de type navigateur lors de la navigation sur des pages web. Ceci est particulièrement pertinent si vous êtes vous-même un fournisseur OAuth2, si votre solution d'authentification sous-jacente est basée sur OAuth2 ou si votre solution de connexion utilise des connexions sociales via des tiers, tels que Google ou GitHub. Dans ces cas, l'emploi d'une WebView devient inévitable en raison de la nécessité d'interagir avec le contenu web et de gérer divers flux d'authentification des utilisateurs, en particulier lorsque des associations d'applications natives sont requises.

En substance, bien que les implémentations natives offrent une expérience utilisateur inégalée et fluide, elles ne sont pas toujours une option viable, surtout lorsqu'elles sont associées à des solutions d'authentification basées sur des mots de passe ou OAuth2. D'un autre côté, les implémentations WebView offrent une voie flexible, bien qu'un peu moins transparente, pour intégrer le contenu web et gérer l'authentification des utilisateurs au sein de votre application, vous assurant de pouvoir naviguer dans les complexités des divers flux d'authentification et des connexions tierces.

Les sections suivantes de cet article se concentrent sur l'implémentation via WebView. Pour en savoir plus sur l'intégration native des passkeys, veuillez consulter cet article.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Plus de 10 000 développeurs font confiance à Corbado et rendent Internet plus sûr avec les passkeys. Des questions ? Nous avons écrit plus de 150 articles de blog sur les passkeys.

Rejoindre la communauté Passkeys

2. Aperçu des options de WebView#

En naviguant dans le labyrinthe de l'authentification dans les applications natives, les développeurs et les chefs de produit sont confrontés à une décision cruciale : implémenter l'authentification par passkey de manière native ou via une WebView. Si l'on opte pour cette dernière, les plateformes iOS et Android offrent deux types distincts de WebViews, chacune avec ses attributs uniques et ses cas d'utilisation potentiels.

2.1 WebViews iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (spécifiquement conçus pour les flux d'authentification basés sur OAuth / OpenID Connect)

2.1 WebViews Android#

WebView
Chrome Custom Tabs (CCT)

Dans les sections suivantes, nous approfondirons ces types de WebView pour vous guider vers une décision éclairée sur la WebView à utiliser pour l'authentification par passkey dans vos applications natives (si une implémentation purement native n'est pas une alternative).

Subscribe to our Passkeys Substack for the latest news.

3. Les WebViews dans iOS#

Les WebViews iOS sont soit WKWebView, soit SFSafariViewController (si vous travaillez avec OAuth / OIDC, il s'agit de SFAuthenticationSession / ASWebAuthenticationSession).

Pour tester les différents comportements des WebViews sous iOS, nous recommandons l'application WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView est une option de WebView puissante et polyvalente disponible pour les développeurs iOS. Introduite avec iOS 8, elle permet aux développeurs d'intégrer du contenu web directement dans une application, offrant un large éventail d'options de personnalisation et de configuration. WKWebView est réputée pour ses performances, utilisant le même moteur de rendu web que Safari, et offrant un riche ensemble d'API pour interagir avec le contenu web, gérer la navigation, les interactions utilisateur, et plus encore.

3.2 SFSafariViewController#

SFSafariViewController est une WebView qui permet aux développeurs de tirer parti des capacités de Safari directement dans leurs applications. Elle offre une expérience utilisateur transparente en utilisant les paramètres Safari de l'utilisateur, tels que les mots de passe enregistrés, les passkeys, les cookies, etc., garantissant une navigation web cohérente, car elle s'exécute en fait comme l'application Safari. SFSafariViewController n'est pas aussi personnalisable que WKWebView mais offre des fonctionnalités de sécurité améliorées et une facilité d'utilisation, ce qui en fait un choix privilégié pour afficher du contenu web simple dans les applications.

	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	- Transparence : Expérience utilisateur transparente utilisant les paramètres Safari de l'utilisateur, garantissant une navigation web cohérente entre l'application native et le navigateur.
Expérience développeur	- Hautement personnalisable : Personnalisation et configuration étendues disponibles - Flexible : 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 lente : Selon l'implémentation et le contenu web, les vitesses de chargement peuvent être optimisées, mais peuvent rester plus lentes par rapport à SFSafariViewController en raison du traitement supplémentaire des fonctionnalités et interactions personnalisées.	- Plutôt rapide : Offre généralement de meilleures performances car elle tire parti du moteur de Safari, qui est 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, ce qui rend plus difficile pour les utilisateurs de vérifier la page web. Potentiel pour les applications malveillantes d'imiter ce comportement et de hameçonner les identifiants.	- Expérience de type navigateur : Affiche les pages web en utilisant Safari, offrant une expérience "de type navigateur". Les utilisateurs peuvent voir l'URL et accéder aux fonctionnalités de remplissage automatique de Safari, ce qui peut inspirer plus de confiance grâce à l'interface familière.
Isolation	- Séparée : Les cookies et les sessions sont séparés de Safari ; les utilisateurs ne seront pas automatiquement connectés dans une WKWebView.	- Séparée : Les cookies et les sessions sont séparés de Safari ; les utilisateurs ne seront pas non plus automatiquement connectés dans SFSafariViewController.
Vulnérabilités	- Sécurisée : Intrinsèquement sécurisée grâce au sandboxing des applications d'Apple, mais le comportement et la sécurité dépendent de l'implémentation de l'application. Vulnérabilités potentielles si elle n'est pas implémentée correctement.	- Plus sécurisée : Bénéficie des fonctionnalités de sécurité intégrées de Safari, y compris les avertissements anti-hameçonnage et contre les sites web malveillants. Généralement considérée comme plus sûre pour afficher du contenu web que WKWebView en raison de ces fonctionnalités et de la familiarité de l'utilisateur avec Safari.
Autre	- Fonctionnalités non disponibles : Certaines fonctionnalités du navigateur (par ex., WebAuthn) peuvent ne pas être entièrement accessibles en raison de préoccupations de sécurité et du fait que WKWebView s'exécute dans le contexte de l'application. - Injection de JavaScript : Certaines applications, par ex. TikTok, injectent du JavaScript de suivi dans leur WKWebView intégrée, ou restreignent le contrôle de l'utilisateur (par ex. Facebook) - Problèmes de confidentialité : Plus de retours de la communauté concernant la confidentialité	- Pas d'injection de JavaScript : Ne permet pas l'exécution de JavaScript depuis l'application, améliorant la sécurité et la confidentialité. De plus, elle ne prend pas en charge les alertes ou confirmations JavaScript, ce qui peut avoir un impact sur l'expérience utilisateur sur certaines pages web. - Mode Lecteur : Fournit un mode lecteur pour une version propre et facile à lire des articles.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession et ASWebAuthenticationSession sont des WebViews spécifiquement conçues pour les flux d'authentification basés sur OAuth / OpenID Connect. Elles fournissent un espace sécurisé et isolé pour l'authentification des utilisateurs, protégeant les identifiants des utilisateurs et garantissant que les informations privées ne sont pas partagées par inadvertance avec l'application. Ces sessions partagent les cookies et les données de site web avec Safari, offrant une expérience utilisateur cohérente et transparente, en particulier pendant les processus d'authentification.

Avantages :

Authentification dédiée : Spécifiquement conçues pour les flux d'authentification basés sur OAuth / OpenID Connect, garantissant un processus d'authentification rationalisé.
Protection de la vie privée : Assure la confidentialité des données des utilisateurs en ne partageant pas les cookies ou les données de site web avec l'application.
Prise en charge du SSO : Prend en charge le Single Sign-On, offrant une expérience utilisateur pratique.

Inconvénients :

Cas d'utilisation limité : Principalement axé sur l'authentification OAuth / OpenID Connect, ce qui peut ne pas convenir à tous les cas d'utilisation.

Lorsque la tâche principale est l'authentification de l'utilisateur, en particulier lors de l'implémentation du SSO ou de l'interaction avec des fournisseurs OAuth, vous devriez utiliser SFAuthenticationSession / ASWebAuthenticationSession au lieu de SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. Les WebViews dans Android#

Les WebViews Android sont soit WebView, soit Chrome Custom Tabs (CCT). Pour tester les différents comportements des WebViews sous Android, nous recommandons l'application WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView sur Android est un composant complet qui permet aux développeurs d'afficher du contenu web dans le cadre de l'interface utilisateur de l'application. Il est polyvalent, offrant un large éventail d'options de personnalisation et donnant aux développeurs la flexibilité de configurer la WebView pour répondre à divers besoins. WebView fournit un riche ensemble d'API pour interagir avec le contenu web, gérer les interactions des utilisateurs, et même gérer les boîtes de dialogue JavaScript, les certificats clients et les demandes de permission.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) offre un moyen transparent, sécurisé et efficace d'intégrer du contenu web directement dans votre application. En tirant parti des capacités et des fonctionnalités de sécurité de Chrome, CCT offre une expérience utilisateur à la fois cohérente et performante.

CCT est un composant du navigateur Chrome, conçu pour s'intégrer au framework Android, permettant aux applications d'ouvrir du contenu web dans un processus léger et dédié. Notamment, il s'ouvre plus rapidement qu'un navigateur conventionnel et, lorsqu'il est préchargé via son appel de préchauffage, il peut potentiellement surpasser une WebView. Bien qu'il exécute du JavaScript, il fonctionne dans son propre processus, protégeant les applications de l'exécution de code malveillant. De plus, l'interface utilisateur de CCT fournit une barre d'action, affichant l'URL et une icône de cadenas de vérification SSL pour les pages sécurisées, rassurant ainsi les utilisateurs sur l'authenticité et la sécurité de la page chargée.

En général, on peut dire que iOS WKWebView et Android WebView, ainsi que SFSafariViewController et Chrome Custom Tabs (CCT) sont similaires.

Caractéristique	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 des utilisateurs, y compris la gestion des boîtes de dialogue JavaScript et des demandes de permission. - Cohérence : La gestion d'une expérience utilisateur cohérente, en particulier avec un contenu web varié, peut être difficile.	- Fonctionnalités du navigateur : Partage des fonctionnalités comme l'Économiseur de données et la saisie semi-automatique synchronisée entre les appareils. - Bouton Retour : Permet aux utilisateurs de revenir facilement à l'application avec un bouton de retour intégré. - Dépendance : Dépend de 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. - Partial Custom Tabs : Seule une partie de l'écran peut être utilisée pour le Chrome Custom Tab tandis que le reste affiche l'application native. - Feuille latérale : En mode paysage et sur les appareils à grand écran, le Chrome Custom Tab n'est affiché que d'un côté de l'écran, tandis que le reste de l'écran affiche l'application native.
Expérience développeur	- Hautement personnalisable : Offre des options/besoins de personnalisation étendus. - Interactivité : Fournit de nombreuses API pour interagir avec le contenu web et gérer les interactions des utilisateurs.	- 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. - Callback : Fournit 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 requêtes, les octrois de permission 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 : L'URL et les informations SSL ne sont pas intrinsèquement visibles dans une 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 hameçonnage.	- URL & SSL visibles : Utilise le navigateur Chrome réel pour afficher 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 hameçonnage.
Isolation	- S'exécute dans le processus de l'application : Si une application a une vulnérabilité qui permet l'exécution de code malveillant, il y a un risque que la WebView puisse être compromise. Cependant, la WebView reçoit également des mises à jour, mais son comportement et sa sécurité peuvent dépendre davantage 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 pouvant obliger 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 ont les mêmes mises à jour de sécurité et fonctionnalités que Chrome. - Pot de cookies et modèle de permissions partagés : Garantit que les utilisateurs n'ont pas à se reconnecter aux sites ou à ré-accorder des permissions. - Paramètres & Préférences de Chrome : Utilise les paramètres et préférences de Chrome.
Vulnérabilités	- Callbacks pour voler des identifiants : Les vulnérabilités potentielles incluent le fait que JavaScript est parfois requis, ce qui ouvre la porte à d'autres applications pour exécuter du code malveillant, comme l'enregistrement de callbacks qui tentent d'intercepter les noms d'utilisateur et les mots de passe. - Hameçonnage : De plus, une application malveillante pourrait ouvrir une autre page web qui imite le flux de liaison dans une tentative de hameçonnage.	- Google Safe Browsing : Emploie la navigation sécurisée de Google pour protéger à la fois l'utilisateur et l'appareil contre les sites dangereux. - Décoration de navigateur sécurisée : Garantit que l'utilisateur voit toujours l'URL exacte avec laquelle il interagit et peut voir les informations du certificat du site web, réduisant le risque de hameçonnage. De plus, les custom tabs ne permettent pas l'injection de JavaScript.
Autre	- Google a interdit les WebViews pour connecter les utilisateurs aux comptes Google

5. Recommandation pour l'implémentation des passkeys dans les applications natives#

Nos clients nous demandent continuellement comment les passkeys devraient être implémentés dans les applications natives. Ces clients peuvent être largement divisés en différents groupes :

Groupe A :

Clients qui commencent à construire leur application native à partir de zéro et peuvent directement utiliser notre authentification sans mot de passe (aucun mot de passe hérité n'existe).

Groupe B :

Clients avec des utilisateurs existants et une solution d'authentification existante. Souvent, ils ont déjà une application web existante qui doit également ajouter des passkeys à son processus d'authentification. Ici, de nombreuses entreprises décident de suivre un processus en deux étapes :

Ajouter les passkeys à votre flux d'authentification WebView existant (c'est ainsi que Google et GitHub l'ont implémenté dans leurs applications natives)
Ajouter les passkeys via une implémentation native par-dessus. Cette implémentation native de passkey vérifie avant l'ancienne WebView (par exemple pour les connexions sociales et les mots de passe) si l'utilisateur peut se connecter avec un passkey (c'est ainsi que KAYAK l'a implémenté dans son application native).

Déterminez votre groupe

Pour fournir à vos utilisateurs la meilleure implémentation de passkey dans une application native, vous devez décider à quel groupe vous appartenez, en fonction de votre configuration technique actuelle et de la manière dont vous souhaitez promouvoir les passkeys (cette question est pertinente pour les entreprises du groupe B).

Recommandation pour le groupe A : Implémentation native

Si vous construisez une toute nouvelle application (groupe A), nous vous recommandons d'opter pour une implémentation native de passkey et de passer complètement au sans mot de passe dès le départ (donc aucun type de WebView n'est utilisé). Veuillez utiliser les SDK et API natifs pour iOS et Android (par exemple via le package Flutter passkeys). Veuillez également lire cet article sur les Relying Party IDs.

Recommandation pour le groupe B : D'abord WebView, puis implémentation native

Si vous ne pouvez pas implémenter les passkeys de manière native aujourd'hui pour une raison quelconque (groupe B), vous pouvez commencer par une implémentation WebView, puis passer à l'avenir à une implémentation native de passkey (cela fonctionne via la création de fichiers d'association, comme apple-app-site-association pour les applications iOS et assetlinks.json pour les applications Android). Les raisons d'opter pour une implémentation WebView peuvent inclure :

Vous offrez déjà une authentification basée sur OAuth2 et souhaitez continuer à l'offrir à vos utilisateurs (OAuth2 ne fonctionne pas de manière native, voir la norme ici)
Vous souhaitez offrir l'authentification par passkey dans la même fenêtre / écran où vous proposez vos autres méthodes d'authentification (par exemple, mots de passe, connexions sociales, OAuth2)

C'est la manière dont Google ou GitHub ont actuellement implémenté l'authentification par passkey dans leurs applications natives. Veuillez consulter la recommandation ci-dessous pour configurer correctement les WebViews pour l'authentification par passkey. Cependant, nous recommandons d'envisager une implémentation native de passkey comme l'a fait KAYAK et de commencer directement par l'étape 2.

Si vous appartenez au groupe B et ne pouvez pas implémenter les passkeys de manière native, notre recommandation penche vers l'utilisation de SFAuthenticationSession / ASWebAuthenticationSession pour iOS et de Chrome Custom Tabs pour Android (sinon les passkeys ne fonctionneront de toute façon pas).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Ci-dessous, nous exposons les raisons de cette recommandation :

5.1 Partage des cookies et des données avec le navigateur#

SFAuthenticationSession / ASWebAuthenticationSession partagent les cookies et les données de site web avec Safari, offrant une expérience utilisateur transparente pendant les processus d'authentification. Il en va de même pour les Chrome Custom Tabs sur Android.

Les utilisateurs bénéficient de leurs mots de passe enregistrés, de leurs données de remplissage automatique et d'autres informations stockées dans le navigateur, ce qui rend le processus d'authentification plus fluide et plus rapide.

5.2 Sécurité renforcée#

SFAuthenticationSession / ASWebAuthenticationSession sur iOS et Chrome Custom Tabs sur Android fournissent un espace sécurisé et isolé pour l'authentification des utilisateurs, garantissant que les identifiants sensibles des utilisateurs sont protégés et non partagés par inadvertance avec l'application ou d'autres sites web.

Ils respectent les protocoles de sécurité stricts d'Apple et de Google, garantissant que les données des utilisateurs sont traitées en toute sécurité et que la confidentialité est maintenue.

De plus, ce choix de conception bénéficie des mises à jour et des améliorations de sécurité continues de Safari et de Chrome, garantissant qu'il respecte les dernières normes et protocoles de sécurité.

5.3 Expérience utilisateur#

SFAuthenticationSession / ASWebAuthenticationSession sur iOS et Chrome Custom Tabs sur Android fournissent une interface utilisateur cohérente et familière, car les utilisateurs sont habitués à l'expérience utilisateur du navigateur. De plus, les paramètres et préférences de l'utilisateur de Safari et de Chrome sont appliqués.

Cela assure une transition en douceur entre le contenu de l'application et le contenu web, garantissant que les utilisateurs ne sont pas déroutés par le passage entre les interfaces.

5.4 Performance#

Les Chrome Custom Tabs tirent parti des performances de Chrome, garantissant une expérience utilisateur fluide et réactive, ce qui est particulièrement crucial pendant les processus d'authentification pour éviter la frustration ou l'abandon de l'utilisateur.

La performance des CCT est souvent supérieure à celle des options Android WebView (de même avec SFAuthenticationSession / ASWebAuthenticationSession sur iOS), garantissant que le contenu web et les flux d'authentification sont gérés rapidement et en douceur.

Voir aussi cette comparaison par Google pour sentir les différences de performance entre les Chrome Custom Tabs, Android WebView et le navigateur Chrome standard.

5.5 Dédié aux flux d'authentification#

SFAuthenticationSession / ASWebAuthenticationSession est spécifiquement conçu pour gérer les flux d'authentification basés sur OAuth / OpenID Connect, garantissant un processus rationalisé et sécurisé pour ces protocoles d'authentification largement utilisés. C'est aussi la méthode recommandée pour l'authentification WebAuthn / passkey.

Sur Android, il n'y a pas de classe dédiée pour les flux d'authentification, mais un comportement similaire peut être implémenté avec les Chrome Custom Tabs et les Android App Links.

De plus, nous nous attendons à ce que davantage d'applications introduisent les passkeys comme TikTok en les collectant simplement lorsque l'utilisateur est authentifié. Cela peut être fait de manière native (implémentation de TikTok) ou via une implémentation WebView. Une approche appropriée consiste à déclencher l'interface utilisateur conditionnelle de manière native. Si cela ne fonctionne pas, vous affichez l'implémentation WebView.

6. Conclusion#

Dans le paysage moderne de l'authentification numérique, l'implémentation des passkeys via WebView dans les applications natives apparaît comme un phare de pratique sécurisée et conviviale. Bien que le parcours pour choisir la WebView optimale puisse être complexe, il est essentiel d'aligner les choix technologiques avec l'expérience utilisateur et la sécurité.