--- url: 'https://www.corbado.com/fr/blog/passkeys-iframe-webauthn' title: 'Passkeys et iframes : comment créer et se connecter avec un passkey ?' description: 'Découvrez comment créer et vous connecter avec des passkeys dans des iframes cross-origin grâce à notre guide. Apprenez-en plus sur les iframes dans WebAuthn, les politiques de sécurité et leur implémentation.' lang: 'fr' author: 'Vincent Delitz' date: '2025-07-15T13:22:28.299Z' lastModified: '2026-03-25T10:05:21.399Z' keywords: 'iframe, cross-origin' category: 'WebAuthn Know-How' --- # Passkeys et iframes : comment créer et se connecter avec un passkey ? ### Référence rapide : Prise en charge des passkeys cross-origin (juillet 2025) | Navigateur | **Connexion cross-origin**
(`navigator.credentials.get`) | **Création cross-origin**
(`navigator.credentials.create`) | | --------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Chrome/Edge** | ✅ [Chrome 84 (juillet 2020)](https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html) | ✅ [Chrome 123 (mars 2024)](https://groups.google.com/a/chromium.org/g/blink-dev/c/Sq2WAVbPz6g) | | **Firefox** | ✅ [Firefox 118 (sept. 2023)](https://bugzilla.mozilla.org/show_bug.cgi?id=1460986) | ✅ [Firefox 123 (fév. 2024)](https://bugzilla.mozilla.org/show_bug.cgi?id=1870863) | | **Safari** | ✅ [Safari 15.5 (mai 2022)](https://bugs.webkit.org/show_bug.cgi?id=222240) | ❌ [Non pris en charge](#62-challenge-2-cross-origin-iframe-issues-with-safari) | **Légende**\ ✅ = pris en charge ❌ = non pris en charge ## 1. Introduction : Comment utiliser les passkeys dans un iframe ? Semaine après semaine, de plus en plus d'organisations annoncent le déploiement des passkeys (par exemple, récemment [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) ou [Vercel](https://www.corbado.com/blog/vercel-passkeys)). 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. 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) - 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. ## 2. Types d'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. ### 2.1 L'iframe de base 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. `` Cet [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) de base est souvent utilisé pour inclure du contenu statique, comme un article, dans une page web. ### 2.2 L'iframe responsive 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. `` Les media queries CSS peuvent également être utilisées pour que l'[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) s'ajuste dynamiquement en fonction de la taille de la fenêtre d'affichage. ### 2.3 L'iframe sécurisé (iframe en bac à sable) Un **iframe sécurisé ou en bac à sable (sandboxed)** restreint les actions qui peuvent être effectuées à l'intérieur de l'[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). C'est utile pour intégrer du contenu de sources non fiables ou pour renforcer la sécurité. ` ` L'attribut **sandbox** peut inclure diverses restrictions, telles que : `` 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. ### 2.4 L'iframe cross-origin / L'iframe inter-sites Les iframes [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn), 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é. 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](https://payment.example.com)** dans une page web hébergée sur **[https://www.mystore.com](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](https://www.example.com/shop)** dans une page web hébergée sur **[https://www.example.com/blog](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é. `` ## 3. Comment les iframes prennent-ils en charge les passkeys ? 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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe), 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](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe)) est déjà intégrée dans la spécification [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) 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. ### 3.1 Se connecter avec des passkeys dans des iframes cross-origin Les tableaux suivants fournissent un aperçu de la prise en charge par les navigateurs/standards de l'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) par iframe et de la connexion par passkey dans des contextes d'iframe cross-origin : | **Navigateur/Standard** | **Contexte First-Party** | **Contexte Third-Party** | | ---------------------------- | ------------------------ | ------------------------ | | Requis dans WebAuthn Level 2 | ✔️ | ✔️ | | Requis dans WebAuthn Level 3 | ✔️ | ✔️ | | Implémenté dans Chrome | ✔️ | ✔️ | | Implémenté dans Firefox | ✔️ | ✔️ | | Implémenté dans Safari | ✔️ | ✔️ | ### 3.2 Créer des passkeys dans des iframes 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 : | **Navigateur/Standard** | **Contexte First-Party** | **Contexte Third-Party** | | ---------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------- | | Requis dans WebAuthn Level 2 | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ❌ | | Requis dans WebAuthn Level 3 | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | | Implémenté dans Chrome | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | | Implémenté dans Firefox | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ✔️ [Détails](https://github.com/mozilla/standards-positions/issues/964) | | Implémenté dans [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | En attente de signal pour l'implémentation | 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](https://github.com/w3c/webauthn/issues/1656) et cette [Pull Request](https://github.com/w3c/webauthn/pull/1801). ### 3.3 Cas d'usage pour les passkeys dans les iframes Il existe deux cas d'usage majeurs pour la prise en charge des passkeys dans les iframes cross-origin. #### 3.3.1 Identité fédérée 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](https://www.corbado.com/blog/kayak-passkeys) et vous avez différents domaines pour différentes régions : - [www.kayak.com](https://www.kayak.com) - [www.kayak.us](https://www.kayak.us) - [www.kayak.de](https://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](https://www.corbado.com/glossary/relying-party)), par exemple [www.kayak.com](http://www.kayak.com). Pour surmonter ce défi, vous utiliseriez un iframe de l'origine [www.kayak.com](https://www.kayak.com) sur tous vos autres domaines. Vous intégrez donc un iframe avec l'origine [www.kayak.com](https://www.kayak.com) sur [www.kayak.us](https://www.kayak.us) et sur [www.kayak.de](https://www.kayak.de) (iframe cross-origin). Sinon, l'utilisation de vos passkeys liés à « [www.kayak.com](https://www.kayak.com) » sur ces autres domaines ne serait pas possible en raison de la résistance au [phishing](https://www.corbado.com/glossary/phishing) des passkeys. Notez également que la nouvelle fonctionnalité de WebAuthn [Related Origin Requests (RoR)](https://passkeys.dev/docs/advanced/related-origins/) pourrait être utilisée comme alternative. Cette fonctionnalité permet aux « [origines liées](https://www.corbado.com/fr/blog/webauthn-origines-liees-passkeys-inter-domaines) » d'accéder aux passkeys sans iframes, mais elle n'est pas encore prise en charge par tous les navigateurs. #### 3.3.2 Paiements L'utilisation des passkeys dans les iframes cross-origin joue également un rôle important pour des flux de [paiement](https://www.corbado.com/passkeys-for-payment) 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](http://www.amazon.com)). Le site web de ce marchand permet au client de payer via son compte bancaire (par exemple chez [www.revolut.com](http://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](https://www.corbado.com/glossary/relying-party) de la banque, par exemple « [revolut](https://www.corbado.com/blog/revolut-passkeys).com ». Pour éviter de rediriger l'utilisateur du site web du marchand ([www.amazon.com](https://www.amazon.com)) vers le site web de la banque ([www.revolut.com](https://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](https://www.amazon.com) et utilise le passkey dans l'iframe cross-origin pour l'authentification qu'il a créé pour [www.revolut.com](https://www.revolut.com). Ainsi, l'intégration des passkeys via des iframes cross-origin dans les flux de [paiement](https://www.corbado.com/passkeys-for-payment) garantit des transactions sécurisées et rationalisées entre les consommateurs, les marchands et les banques : | **Consommateurs** | **Marchands** | **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](https://www.corbado.com/fr/blog/liaison-dynamique-passkeys-spc) 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](https://www.corbado.com/blog/vuejs-passkeys) plus approfondie des flux de paiement cross-origin utilisant les passkeys, consultez notre article Passkeys pour Fournisseurs de Paiement : Comment construire un SDK tiers. ## 4. Avantages de l'utilisation des passkeys dans les iframes 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](https://www.corbado.com/passkeys-for-payment), 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. ## 5. Guide étape par étape pour implémenter les passkeys dans les iframes 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/](https://cross-origin-iframe.vercel.app/). ![Démo de passkey dans un iframe cross-origin](https://www.corbado.com/website-assets/cross_origin_iframe_passkey_demo_8879588a51.png) ### 5.1 Définir la politique d'autorisation sur publickey-credentials-get et publickey-credentials-create 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get) et [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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})`). `` 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](https://developer.chrome.com/docs/privacy-security/permissions-policy) pour plus de détails sur l'implémentation. ### 5.2 Configurer les en-têtes HTTP Assurez-vous que les en-têtes de réponse HTTP de l'URL source de l'iframe incluent la `[Permissions-Policy](https://www.corbado.com/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")` ### 5.3 Gérer l'activation par l'utilisateur 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](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation). ```javascript document.getElementById('loginPasskeyButton').addEventListener('click', async () => { try { const [publicKeyCredentialRequestOptions](https://www.corbado.com/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. ### 5.4 Exemple d'implémentation Ci-dessous, vous trouverez un exemple complet de code d'un fichier `index.html` hébergé sur [https://cross-origin-iframe.vercel.com](https://cross-origin-iframe.vercel.com) qui utilise un iframe cross-origin pour les passkeys via [https://passkeys.eu](https://passkeys.eu). ```html Démo d'iframe cross-origin avec Passkeys

Démo d'iframe cross-origin avec Passkeys

``` ## 6. Défis courants et comment les surmonter 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. ### 6.1 Défi 1 : Configuration de la politique d'autorisation **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 : ![configuration de la politique d'autorisation de l'iframe pour passkey](https://www.corbado.com/website-assets/passkey_iframe_permission_policy_configuration_4819cbebec.png) **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 `` 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** : ![fonctionnalités autorisées de la politique d'autorisation pour passkey](https://www.corbado.com/website-assets/passkey_permissions_policy_allowed_features_ffadbc4302.png) ### 6.2 Défi 2 : Problèmes d'iframe cross-origin avec Safari **Problème :** La [création de passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-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](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) depuis l'iframe, car Safari ne prend pas en charge la [création de passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) dans un iframe cross-origin (voir ci-dessus). ![erreur non autorisée de l'iframe pour passkey](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png) **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](https://passkeys.eu)" from accessing a frame with origin "[https://cross-origin-iframe.vercel.app](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](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) ou l'accès au LocalStorage dans un contexte tiers, certaines parties de la logique JavaScript pourraient être interrompues. ![cookie tiers de l'iframe pour passkey](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png) **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. ### 6.3 Défi 3 : Compatibilité des navigateurs **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. ### 6.4 Défi 4 : Les iframes dans les applications natives **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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) ou de connexion. Dans une **WebView intégrée (EWV)** telle que [WKWebView](https://www.corbado.com/blog/native-app-passkeys) sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ou une [WebView](https://www.corbado.com/blog/native-app-passkeys) [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys) sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ou les Custom Tabs sur [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/native-app-passkeys), donc si Safari ne permet pas certaines opérations de passkey dans les iframes tiers, il en sera de même dans la [WebView](https://www.corbado.com/blog/native-app-passkeys) 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. 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. ## 7. Note supplémentaire pour les fournisseurs de paiement : iframes cross-origin et SDK 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](https://www.corbado.com/blog/native-app-passkeys) sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-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é : En particulier : - [**Stratégie A : Intégrer un iframe cross-origin**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#51-strategy-a-embedding-a-cross-origin-iframe-pros--cons) 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**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#52-strategy-b-redirect-based-approach-for-broader-compatibility) 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](https://www.corbado.com/glossary/phishing) directement à l'intérieur d'un iframe, débloquant ainsi le prochain niveau de sécurité et d'UX pour les [paiements](https://www.corbado.com/passkeys-for-payment) en ligne. ## 8. Conclusion 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](https://shopify.engineering/supporting-passkeys-in-shop-authentication-flows) dans leur composant de connexion, démontrent les avantages pratiques et la flexibilité de cette approche.