Passkeys et iframes : comment créer et se connecter avec un passkey ?

Légende
✅ = pris en charge ❌ = non pris en charge

Semaine après semaine, de plus en plus d'organisations annoncent le déploiement des passkeys (par exemple, récemment Visa, Mastercard ou Vercel). Alors que les développeurs et les chefs de produit d'autres entreprises suivent ces exemples, de nouveaux cas d'usage pour l'implémentation des passkeys sont discutés.

Un cas sur lequel on nous interroge constamment est le fonctionnement des passkeys dans les iframes, car les iframes sont largement utilisées dans le développement web moderne pour intégrer de manière transparente du contenu provenant de différentes sources. Dans le contexte des passkeys et de WebAuthn, les iframes présentent leur propre lot de défis, notamment en ce qui concerne la sécurité et les interactions avec l'utilisateur.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Cet article de blog fournit un guide complet sur l'utilisation des passkeys et de WebAuthn dans les iframes. Nous allons :

• Explorer les capacités actuelles
• Discuter de la prise en charge des iframes cross-origin
• Mettre en évidence les avantages de l'intégration des iframes et
• Fournir un guide d'implémentation étape par étape

À la fin de cet article, vous comprendrez clairement comment tirer parti des passkeys au sein des iframes.

Les iframes, ou cadres en ligne, sont des éléments HTML qui permettent aux développeurs d'intégrer un autre document HTML au sein du document actuel. Cette capacité est largement utilisée pour incorporer du contenu de sources externes, comme des vidéos, des cartes et d'autres pages web, dans un site web.

Jetons un œil aux différents types d'iframes.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

L'iframe de base est le type le plus couramment utilisé. Il intègre simplement du contenu d'une autre URL dans la page actuelle.

<iframe src="https://example.com"></iframe>

Cet iframe de base est souvent utilisé pour inclure du contenu statique, comme un article, dans une page web.

Les iframes responsives sont conçus pour ajuster leur taille en fonction de la taille de l'écran ou du conteneur dans lequel ils sont placés. Cela garantit que le contenu intégré s'affiche correctement sur tous les appareils, y compris les ordinateurs de bureau, les tablettes et les téléphones mobiles.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

Les media queries CSS peuvent également être utilisées pour que l'iframe s'ajuste dynamiquement en fonction de la taille de la fenêtre d'affichage.

Get a free passkey assessment in 15 minutes.

Book free consultation

Un iframe sécurisé ou en bac à sable (sandboxed) restreint les actions qui peuvent être effectuées à l'intérieur de l'iframe. C'est utile pour intégrer du contenu de sources non fiables ou pour renforcer la sécurité.

<iframe src="https://example.com" sandbox></iframe>

L'attribut sandbox peut inclure diverses restrictions, telles que :

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

L'attribut sandbox autorise l'exécution de scripts mais restreint les actions potentiellement dangereuses, comme la soumission de formulaires ou l'utilisation de plugins.

Become part of our Passkeys Community for updates & support.

Join

Les iframes cross-origin intègrent du contenu provenant d'un domaine différent. Ils sont couramment utilisés pour intégrer des services tiers, tels que des passerelles de paiement ou des widgets de réseaux sociaux. En raison des restrictions de sécurité, ces iframes ont un accès limité au contenu de la page d'intégration et vice versa.

Cross-origin signifie que le contenu chargé provient d'une origine différente, où une origine est définie par la combinaison du schéma (protocole), de l'hôte (domaine) et du numéro de port. Par exemple, https://example.com et http://example.com sont considérés comme des origines différentes car ils utilisent des schémas différents (HTTP vs. HTTPS).

De même, les sous-domaines sont traités comme des origines distinctes de leurs domaines parents. Par exemple, https://example.com et https://sub.example.com sont cross-origin, même s'ils partagent le même domaine de base. Cette séparation garantit que les scripts et les données d'un sous-domaine ne peuvent pas interagir directement avec ceux d'un autre sans autorisation explicite, ce qui renforce la sécurité.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

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

Les entreprises font confiance à Corbado pour protéger leurs utilisateurs et fluidifier les connexions avec les passkeys. Obtenez dès maintenant votre consultation gratuite sur les passkeys.

Obtenez une consultation gratuite

Voici des exemples pour illustrer les concepts de cross-origin et de même origine :

Exemple cross-origin :

Intégrer du contenu de https://payment.example.com dans une page web hébergée sur https://www.mystore.com. C'est cross-origin car ils ont des domaines différents.

Exemple de même origine :

Intégrer du contenu de https://www.example.com/shop dans une page web hébergée sur https://www.example.com/blog. C'est de même origine car ils partagent le même schéma, hôte et port.

Les iframes cross-origin diffèrent des iframes de base en ce que la source provient d'un autre domaine, alors qu'un iframe de même site a sa source sur le même domaine que celui où il est intégré.

<iframe src="https://anotherdomain.com"></iframe>

L'utilisation des passkeys dans les iframes introduit de nouvelles capacités et contraintes que les développeurs doivent comprendre, tournant principalement autour de la définition des bonnes autorisations et de la garantie d'interactions utilisateur sécurisées dans le contexte intégré.

Historiquement, l'API Web Authentication était désactivée par défaut dans les iframes cross-origin, principalement pour des raisons de sécurité. Cette limitation signifiait que les développeurs devaient rediriger les utilisateurs ou utiliser des fenêtres pop-up pour l'authentification, ce qui entraînait une expérience utilisateur moins fluide.

Dans les passkeys / WebAuthn, il y a deux opérations principales (également appelées cérémonies) :

1. S'inscrire / créer un passkey
2. S'authentifier / se connecter avec un passkey

Ces deux opérations n'ont pas été et ne sont pas prises en charge de la même manière dans les iframes cross-origin :

Au début, la connexion via des iframes cross-origin a été rendue possible, mais la création cross-origin ne l'était pas encore car personne n'avait de cas d'usage.

Des avancées récentes (par exemple dans Chrome 123) ont introduit la prise en charge de la création de passkeys dans des iframes cross-origin sous des conditions spécifiques. Cependant, en mai 2024, tous les navigateurs ne prennent pas entièrement en charge la création de passkeys via des iframes cross-origin, bien que la connexion soit possible avec la plupart des navigateurs.

De plus, la prise en charge des iframes cross-origin (pour les opérations d'inscription et d'authentification) est déjà intégrée dans la spécification WebAuthn Level 3 en cours. Certains navigateurs doivent encore rattraper leur retard sur la spécification (par exemple Safari). Malheureusement, Apple n'a pas encore annoncé si et quand il autorisera l'enregistrement cross-origin de passkeys dans Safari. Cela lèverait la limitation technique la plus importante pour l'utilisation des passkeys dans les iframes cross-origin.

Dans les parties suivantes de cet article de blog, nous supposons l'utilisation d'iframes cross-origin.

Want to find out how many people use passkeys?

View Adoption Data

Les tableaux suivants fournissent un aperçu de la prise en charge par les navigateurs/standards de l'authentification par iframe et de la connexion par passkey dans des contextes d'iframe cross-origin :

En mai 2024, la création d'un passkey dans un iframe cross-origin n'est pas encore possible dans tous les navigateurs. Le tableau suivant fournit un aperçu de la prise en charge par les navigateurs / standards pour l'enregistrement / la création de passkeys dans des iframes cross-origin :

Si vous êtes intéressé par plus de détails sur ce développement et cette prise en charge, nous vous recommandons de consulter cette issue GitHub et cette Pull Request.

Il existe deux cas d'usage majeurs pour la prise en charge des passkeys dans les iframes cross-origin.

L'activation des passkeys dans les iframes cross-origin est cruciale pour les scénarios d'identité fédérée où plusieurs domaines sont impliqués mais où les mêmes comptes utilisateurs doivent être utilisés.

Prenons le scénario suivant. Vous êtes une entreprise multinationale comme KAYAK et vous avez différents domaines pour différentes régions :

• www.kayak.com
• www.kayak.us
• www.kayak.de

Cependant, vous avez un système de gestion d'identité central qui permet aux utilisateurs de se connecter avec le même compte et les mêmes identifiants sur tous ces domaines. Le standard WebAuthn poserait un défi à ces scénarios, car les passkeys ne peuvent être liés qu'à un seul domaine (ID de Relying Party), par exemple www.kayak.com.

Pour surmonter ce défi, vous utiliseriez un iframe de l'origine www.kayak.com sur tous vos autres domaines. Vous intégrez donc un iframe avec l'origine www.kayak.com sur www.kayak.us et sur www.kayak.de (iframe cross-origin). Sinon, l'utilisation de vos passkeys liés à « www.kayak.com » sur ces autres domaines ne serait pas possible en raison de la résistance au phishing des passkeys.

Notez également que la nouvelle fonctionnalité de WebAuthn Related Origin Requests (RoR) pourrait être utilisée comme alternative. Cette fonctionnalité permet aux « origines liées » d'accéder aux passkeys sans iframes, mais elle n'est pas encore prise en charge par tous les navigateurs.

L'utilisation des passkeys dans les iframes cross-origin joue également un rôle important pour des flux de paiement fluides. Considérez le scénario suivant : un client souhaite acheter de nouvelles chaussures sur le site web d'un marchand (par exemple www.amazon.com). Le site web de ce marchand permet au client de payer via son compte bancaire (par exemple chez www.revolut.com) et exige donc que l'utilisateur se connecte au site web de la banque (c'est un processus simplifié). L'utilisateur se connecte au site web de la banque avec un passkey qui est lié à l'ID de Relying Party de la banque, par exemple « revolut.com ».

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Pour éviter de rediriger l'utilisateur du site web du marchand (www.amazon.com) vers le site web de la banque (www.revolut.com) lors du processus de paiement et de le laisser se connecter à son compte bancaire là-bas, un iframe cross-origin peut être utilisé. Ainsi, l'utilisateur reste sur www.amazon.com et utilise le passkey dans l'iframe cross-origin pour l'authentification qu'il a créé pour www.revolut.com.

Ainsi, l'intégration des passkeys via des iframes cross-origin dans les flux de paiement garantit des transactions sécurisées et rationalisées entre les consommateurs, les marchands et les banques :

Dans le contexte du paiement et des passkeys, nous vous recommandons également de consulter notre article de blog sur la Confirmation de Paiement Sécurisée (SPC) et la liaison dynamique avec les passkeys. Assurez-vous également de consulter les limitations pour le contexte tiers dans les applications natives ci-dessous.

De plus, pour une vue plus approfondie des flux de paiement cross-origin utilisant les passkeys, consultez notre article Passkeys pour Fournisseurs de Paiement : Comment construire un SDK tiers.

En général, l'intégration des passkeys dans les iframes offre plusieurs avantages, principalement en améliorant l'expérience utilisateur (UX) et la sécurité. Voici une ventilation de ces avantages :

Expérience utilisateur améliorée

1. Pas de pop-ups ni de redirections : Les utilisateurs peuvent s'authentifier directement dans le contenu intégré sans redirections ni pop-ups, ce qui se traduit par une expérience plus fluide et moins perturbatrice.
2. UX cohérente sur tous les sites : L'intégration des flux d'authentification dans les iframes garantit une expérience utilisateur cohérente dans différentes sections d'un site web ou sur différents sites web qui utilisent le même service d'authentification.

Sécurité améliorée

1. Transactions sécurisées : Pour des scénarios comme les paiements, les passkeys dans les iframes renforcent la sécurité des transactions en garantissant que l'authentification se déroule dans un contexte intégré et sécurisé.
2. Utilisation d'un compte utilisateur sur différents sites web : Dans les configurations d'identité fédérée, les passkeys dans les iframes cross-origin permettent une vérification d'identité sécurisée et efficace sur plusieurs domaines.

L'implémentation des passkeys dans les iframes implique quelques étapes clés pour garantir la sécurité et la fonctionnalité. Nous fournissons un guide détaillé pour les développeurs. Veuillez également consulter l'exemple d'implémentation sur https://cross-origin-iframe.vercel.app/.

L'en-tête HTTP Permissions-Policy aide à autoriser ou à refuser l'utilisation de certaines fonctionnalités du navigateur dans un document ou dans un élément iframe. Pour activer les connexions par passkey dans un iframe, vous devez définir les politiques d'autorisation publickey-credentials-get et publickey-credentials-create. Ces politiques permettent au contenu intégré d'invoquer la méthode de l'API WebAuthn nécessaire pour s'authentifier (navigator.credentials.get({publicKey})) et créer un passkey (navigator.credentials.create({publicKey})).

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

L'en-tête HTTP Permissions Policy s'appelait auparavant Feature Policy. Sous Feature Policy, vous pouviez accorder une fonctionnalité à un iframe cross-origin soit en ajoutant l'origine à la liste d'origines de l'en-tête, soit en incluant un attribut allow dans la balise iframe. Avec Permissions Policy, l'ajout d'un cadre cross-origin à la liste d'origines nécessite que la balise iframe pour cette origine inclue l'attribut allow. Si la réponse ne contient pas d'en-tête Permissions Policy, la liste d'origines est par défaut * (toutes les origines). L'inclusion de l'attribut allow dans l'iframe accorde l'accès à la fonctionnalité.

Pour s'assurer que les iframes cross-origin non spécifiés dans la liste d'origines sont bloqués d'accéder à la fonctionnalité, même si l'attribut allow est présent, les développeurs peuvent explicitement définir l'en-tête Permissions Policy dans la réponse.

Dans Chrome 88+, Feature Policy peut toujours être utilisé mais agit comme un alias pour Permissions Policy. Hormis les différences de syntaxe, la logique reste la même. Lorsque les en-têtes Permissions Policy et Feature Policy sont utilisés simultanément, l'en-tête Permissions Policy a la priorité et remplacera la valeur définie par l'en-tête Feature Policy. Veuillez également consulter cet article de blog de l'équipe Chrome pour plus de détails sur l'implémentation.

Assurez-vous que les en-têtes de réponse HTTP de l'URL source de l'iframe incluent la [Permissions-Policy](/blog/iframe-passkeys-webauthn/enable-passkeys-iframe) pertinente. C'est crucial pour la prise en charge cross-origin.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

Pour un contrôle plus granulaire, vous pouvez spécifier les origines particulières autorisées à intégrer le contenu de l'iframe.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

Assurez-vous que le contenu de l'iframe nécessite une action de l'utilisateur pour déclencher l'authentification par passkey. Cela peut être fait en utilisant des écouteurs d'événements pour les clics ou les soumissions de formulaires dans l'iframe. Ce processus est également appelé activation transitoire.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Options de configuration */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Gérer l'identifiant créé
        } catch (err) {
            console.error('Erreur d\'authentification via passkey :', err);
        }
    });

Dans ce contexte, consultez également notre article de blog sur les exigences de geste de l'utilisateur de Safari.

Ci-dessous, vous trouverez un exemple complet de code d'un fichier index.html hébergé sur https://cross-origin-iframe.vercel.com qui utilise un iframe cross-origin pour les passkeys via https://passkeys.eu.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Démo d'iframe cross-origin avec Passkeys</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Démo d'iframe cross-origin avec Passkeys</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

L'implémentation des passkeys dans les iframes peut s'accompagner d'un ensemble de défis que les développeurs doivent relever pour garantir une expérience utilisateur fluide et sécurisée. Voici un aperçu détaillé des défis courants et comment les surmonter.

Problème : Une configuration incorrecte des politiques d'autorisation peut empêcher l'iframe d'accéder aux API WebAuthn.

« NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames. »

Si vous n'ajoutez pas correctement les politiques d'autorisation, le navigateur lèvera l'erreur suivante :

Solution :

• Vérifiez que l'attribut allow et les en-têtes HTTP sont définis : Assurez-vous que l'attribut allow et les en-têtes HTTP sont correctement définis. Vérifiez que les autorisations publickey-credentials-get et publickey-credentials-create sont incluses à la fois dans l'élément iframe et dans les en-têtes de réponse HTTP du serveur.
• En-têtes Meta au lieu des en-têtes du serveur web : Utilisez des en-têtes <meta/> pour définir les politiques d'autorisation au lieu de définir les en-têtes dans votre serveur web.
• Point-virgule au lieu de virgule dans Permissions-Policy : Auparavant, Permissions-Policy s'appelait Feature-Policy. Les éléments uniques d'une Feature-Policy étaient séparés par une virgule au lieu d'un point-virgule (qui est la norme pour Permissions-Policy). La Permissions-Policy de l'iframe suit toujours la syntaxe de Feature-Policy et utilise donc des virgules. Les attributs sandbox / allow sont cependant toujours séparés par un point-virgule (voir l'extrait de code ci-dessus).

Astuce : Pour tester correctement que vos en-têtes Permission-Policy sont bien définis, nous recommandons d'ouvrir les outils de développement de votre navigateur, d'accéder à Application (ici : dans les outils de développement de Chrome), d'aller dans Frames et de rechercher l'origine de l'iframe (ici : passkeys.eu/). Si la Permissions-Policy est correctement définie, publickey-credential-create et publickey-credential-get devraient être listés parmi les Fonctionnalités autorisées :

Problème : La création de passkey ou la connexion par passkey dans un iframe cross-origin ne fonctionne pas, et vous voyez l'erreur suivante dans la console de votre navigateur.

« NotAllowedError - The origin of the document is not the same as its ancestors. »

Cette erreur apparaît lors de l'utilisation du navigateur Safari et de la tentative de créer un passkey depuis l'iframe, car Safari ne prend pas en charge la création de passkey dans un iframe cross-origin (voir ci-dessus).

Solution : Ici, vous ne pouvez pas vraiment faire grand-chose car Safari ne prend pas encore en charge la création d'un passkey depuis un iframe cross-origin (pour le moment).

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

Cette erreur n'est pas directement liée aux passkeys mais plutôt aux iframes cross-origin dans Safari en général. Dans le cadre de l'initiative de Safari / WebKit pour bloquer les cookies tiers ou l'accès au LocalStorage dans un contexte tiers, certaines parties de la logique JavaScript pourraient être interrompues.

Solution : Ici, vous devez vous assurer que vous n'utilisez pas de cookies tiers à l'intérieur de vos iframes, car cela provoque une erreur.

Problème : Des problèmes de compatibilité des navigateurs avec les iframes surviennent lorsque différents navigateurs ont des niveaux de prise en charge variables pour WebAuthn, les autorisations d'iframe et les attributs de sécurité, ce qui entraîne un comportement incohérent.

Solution : Pour atténuer ces problèmes de compatibilité des navigateurs avec les iframes, testez l'implémentation sur plusieurs navigateurs pour garantir la compatibilité et identifier tout problème spécifique à un navigateur.

Étapes :

1. Effectuez des tests multi-navigateurs à l'aide d'outils comme BrowserStack ou Sauce Labs.
2. Corrigez les divergences en implémentant des correctifs ou des solutions de repli spécifiques aux navigateurs.

Problème : Lors de l'utilisation d'iframes nécessitant des passkeys dans des applications natives, une distinction cruciale doit être faite entre les contextes first-party et third-party :

• Contexte first-party : Les passkeys sont liés au même domaine que l'entreprise qui gère l'application. Par exemple, une application de e-commerce qui s'appuie sur son propre domaine pour l'authentification des utilisateurs.
• Contexte third-party : Un domaine différent (par exemple, un fournisseur de paiement ou un fournisseur d'identité) gère le flux de création de passkey ou de connexion.

Dans une WebView intégrée (EWV) telle que WKWebView sur iOS ou une WebView Android - l'application appelante a un contrôle étendu sur la session web (par exemple, l'interception des requêtes). Cette configuration ne prend généralement en charge les passkeys que si le domaine du passkey (l'ID de Relying Party) correspond au domaine de l'application (first-party). Cependant, dans un scénario third-party - comme le flux cross-origin d'un fournisseur de paiement - une WebView intégrée ne peut généralement pas accéder aux informations d'identification de passkey nécessaires car l'application du marchand et le service du fournisseur de paiement sont des origines différentes. Les « liaisons » requises pour les passkeys (entre le domaine, l'identifiant et l'origine) ne correspondront pas dans le contexte intégré.

Cette limitation conduit de nombreuses applications à adopter une approche de WebView système (par exemple, ASWebAuthenticationSession sur iOS ou les Custom Tabs sur Android). Les WebViews système isolent le site tiers (par exemple, le fournisseur de paiement) dans un environnement sécurisé de type navigateur qui autorise correctement les passkeys cross-origin — si le navigateur lui-même le prend en charge. Néanmoins, n'oubliez pas que les limitations existantes de Safari pour les iframes s'appliquent également à ASWebAuthenticationSession, donc si Safari ne permet pas certaines opérations de passkey dans les iframes tiers, il en sera de même dans la WebView système. Il n'y a actuellement pas de solution « native » ; la meilleure pratique pour les flux complexes - tels que les paiements impliquant des fournisseurs de paiement externes - est d'ouvrir une WebView système plutôt qu'une WebView intégrée.

Solution : Pour les fournisseurs de paiement (et autres tiers s'appuyant sur les passkeys sur plusieurs domaines), planifiez soigneusement l'intégration pour vous assurer que l'utilisateur est sorti d'une WebView intégrée et dirigé vers une WebView système. Bien que ce soit une expérience moins fluide qu'un flux purement intégré, c'est souvent le seul moyen de garantir que la fonctionnalité de passkey fonctionnera avec les services tiers.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Pour plus de détails sur la gestion des passkeys tiers dans les applications natives et les WebViews, consultez Passkeys pour Fournisseurs de Paiement : SDK de paiement pour passkeys tiers.

Bien que les sujets abordés ci-dessus s'appliquent à divers scénarios, ils sont particulièrement importants pour les fournisseurs de paiement, où les flux multi-domaines (par exemple, le site du marchand et la passerelle de paiement) doivent intégrer l'authentification des utilisateurs dans des iframes cross-origin. Dans ces configurations :

• Les utilisateurs veulent un paiement fluide, sur la page, sans pop-ups de redirection.
• Les fournisseurs de paiement doivent gérer l'enregistrement ou la connexion par passkey sur leur propre domaine (par exemple, pay.provider.com), même s'ils sont intégrés dans le site d'un marchand.
• Les contraintes de Safari et les limitations des WebView intégrées bloquent souvent la création de passkeys tiers dans les iframes.

Pour relever ces défis et construire une expérience sécurisée et fluide similaire à Apple Pay, les fournisseurs de paiement adoptent souvent une approche hybride - combinant l'intégration basée sur les iframes avec une solution de repli par redirection pour Safari (ou les navigateurs plus anciens). Dans certains cas, les flux de navigateur système (par exemple, ASWebAuthenticationSession sur iOS) deviennent obligatoires si une WebView intégrée ne permet pas du tout les passkeys.

Pour une analyse approfondie de ces scénarios spécifiques aux paiements - y compris des comparaisons iframe vs. redirection, des considérations sur les applications natives et les meilleures pratiques pour une forte adoption des passkeys, consultez notre article dédié :

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

Get free Whitepaper

En particulier :

• Stratégie A : Intégrer un iframe cross-origin explique comment gérer la création et la connexion par passkey en ligne, en faisant référence aux paramètres Permissions-Policy présentés ici.
• Stratégie B : Approche basée sur la redirection montre une intégration plus simple qui contourne la plupart des pièges cross-origin, bien qu'au prix de quitter le domaine du marchand.
• La WebView système est essentielle pour les applications natives, car les WebViews intégrées cassent fréquemment les flux de passkeys tiers.

Ce guide complémentaire fournit des stratégies approfondies pour sécuriser les transactions, surmonter les restrictions cross-origin de Safari et optimiser l'utilisation des passkeys dans des contextes tiers. En combinant les étapes techniques de cet article avec ces méthodes axées sur le paiement, vous pouvez offrir un flux de paiement fluide et résistant au phishing directement à l'intérieur d'un iframe, débloquant ainsi le prochain niveau de sécurité et d'UX pour les paiements en ligne.

L'intégration des passkeys dans les iframes améliore considérablement l'authentification des utilisateurs en améliorant à la fois la sécurité et l'expérience utilisateur. Cela permet une authentification transparente sans avoir besoin de redirections ou de pop-ups, garantissant une UX cohérente sur diverses sections et sites.

Des implémentations concrètes, telles que l'intégration des passkeys par Shopify dans leur composant de connexion, démontrent les avantages pratiques et la flexibilité de cette approche.