--- url: 'https://www.corbado.com/pt/blog/passkeys-iframes-webauthn' title: 'Passkeys e iframes: como criar e fazer login com uma passkey?' description: 'Descubra como criar e fazer login com passkeys em iframes de origem cruzada com o nosso guia. Saiba mais sobre iframes no WebAuthn, políticas de segurança e implementação.' lang: 'pt' author: 'Vincent Delitz' date: '2025-07-15T13:22:37.449Z' lastModified: '2026-08-29T06:03:11.362Z' keywords: 'iframe, origem cruzada, cross-origin, passkeys' category: 'WebAuthn Know-How' --- # Passkeys e iframes: como criar e fazer login com uma passkey? ### Referência Rápida: Suporte a Passkeys de Origem Cruzada (Julho de 2025) | Navegador | **Login de origem cruzada**
(`navigator.credentials.get`) | **Criação de origem cruzada**
(`navigator.credentials.create`) | | --------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- | | **Chrome/Edge** | ✅ [Chrome 84 (Julho de 2020)](https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html) | ✅ [Chrome 123 (Março de 2024)](https://groups.google.com/a/chromium.org/g/blink-dev/c/Sq2WAVbPz6g) | | **Firefox** | ✅ [Firefox 118 (Setembro de 2023)](https://bugzilla.mozilla.org/show_bug.cgi?id=1460986) | ✅ [Firefox 123 (Fevereiro de 2024)](https://bugzilla.mozilla.org/show_bug.cgi?id=1870863) | | **Safari** | ✅ [Safari 15.5 (Maio de 2022)](https://bugs.webkit.org/show_bug.cgi?id=222240) | ❌ [Não suportado](#62-desafio-2-problemas-com-iframes-de-origem-cruzada-no-safari) | **Legenda**\ ✅ = suportado ❌ = não suportado ## 1. Introdução: Como Usar Passkeys num iframe? Semana após semana, cada vez mais organizações anunciam a implementação de passkeys (por exemplo, recentemente a [Visa](https://www.corbado.com/blog/visa-passkeys), a [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) ou a [Vercel](https://www.corbado.com/blog/vercel-passkeys)). À medida que programadores e gestores de produto de outras empresas seguem estes exemplos, mais casos de uso para a implementação de passkeys são discutidos. Um caso sobre o qual nos perguntam constantemente é **como as passkeys funcionam em iframes**, uma vez que os iframes são amplamente utilizados no desenvolvimento web moderno para incorporar conteúdo de diferentes fontes de forma integrada. No contexto de passkeys e WebAuthn, os iframes trazem o seu próprio conjunto de desafios, especialmente no que diz respeito à [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve) e às interações do utilizador. Este artigo do blogue oferece um **guia completo sobre o uso de passkeys e WebAuthn em iframes**. Nós vamos: - Explorar as capacidades atuais - Discutir o suporte para iframes de origem cruzada - Destacar os benefícios da integração com iframes e - Fornecer um guia de implementação passo a passo No final deste post, terá uma compreensão clara de como aproveitar as passkeys dentro de iframes. ## 2. Tipos de iframes iframes, ou frames em linha, são elementos HTML que permitem aos programadores incorporar outro documento HTML dentro do documento atual. Esta capacidade é amplamente utilizada para incorporar conteúdo de fontes externas, como vídeos, mapas e outras páginas web, num website. Vamos dar uma olhada nos diferentes tipos de iframes. ### 2.1 iframe Básico O **iframe básico** é o tipo mais comummente utilizado. Ele simplesmente incorpora conteúdo de outro URL dentro da página atual. `` Este [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) básico é frequentemente usado para incluir conteúdo estático, como um artigo, dentro de uma página web. ### 2.2 iframe Responsivo **iframes responsivos** são projetados para ajustar o seu tamanho com base no tamanho do ecrã ou do contentor em que são colocados. Isso garante que o conteúdo incorporado tenha uma boa aparência em todos os dispositivos, incluindo desktops, tablets e telemóveis. `` As media queries de CSS também podem ser usadas para fazer o [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) ajustar-se dinamicamente com base no tamanho da viewport. ### 2.3 iframe Seguro (iframe em Sandbox) **Um iframe seguro ou em sandbox** restringe as ações que podem ser executadas dentro do [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). Isso é útil para incorporar conteúdo de fontes não confiáveis ou para aumentar a [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve). ` ` O atributo **sandbox** pode incluir várias restrições, tais como: `` O atributo **sandbox** permite que scripts sejam executados, mas restringe ações potencialmente perigosas, como submissões de formulários ou uso de plugins. ### 2.4 iframe de Origem Cruzada / iframe Cross-Site iframes de origem cruzada incorporam conteúdo de um domínio diferente. São comummente usados para integrar serviços de terceiros, como gateways de [pagamento](https://www.corbado.com/passkeys-for-payment) ou widgets de redes sociais. Devido a restrições de [segurança](https://www.corbado.com/pt/blog/senhas-complexas-quebradas-em-breve), estes iframes têm acesso limitado ao conteúdo da página que os incorpora e vice-versa. **Origem cruzada (cross-origin) significa que o conteúdo a ser carregado vem de uma origem diferente**, onde uma origem é definida pela combinação do esquema (protocolo), anfitrião (domínio) e número da porta. Por exemplo, `https://example.com` e `http://example.com` são consideradas origens diferentes porque usam esquemas diferentes (HTTP vs. HTTPS). Da mesma forma, os subdomínios são tratados como origens separadas dos seus [domínios](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) principais. Por exemplo, `https://example.com` e `https://sub.example.com` são de origem cruzada, mesmo que partilhem o mesmo domínio base. Esta separação garante que scripts e dados de um subdomínio não possam interagir diretamente com os de outro sem permissão explícita, aumentando a segurança. Aqui estão exemplos para ilustrar os conceitos de origem cruzada e mesma origem: **Exemplo de origem cruzada:** Incorporar conteúdo de **[https://payment.example.com](https://payment.example.com)** numa página web alojada em **[https://www.mystore.com](https://www.mystore.com)**. Estas são de origem cruzada porque têm [domínios](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) diferentes. **Exemplo de mesma origem:** Incorporar conteúdo de **[https://www.example.com/shop](https://www.example.com/shop)** numa página web alojada em **[https://www.example.com/blog](https://www.example.com/blog)**. Estas são da mesma origem porque partilham o mesmo esquema, anfitrião e porta. Os iframes de origem cruzada diferem dos iframes básicos no facto de a fonte ser de outro domínio, enquanto um iframe do mesmo site tem a sua fonte no mesmo domínio onde está incorporado. `` ## 3. Como os iframes Suportam Passkeys? O uso de passkeys em iframes introduz novas capacidades e restrições que os programadores precisam de entender, principalmente em torno da definição das permissões corretas e da garantia de interações seguras do utilizador no contexto incorporado. Historicamente, a API de [Autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) da Web (WebAuthn) era desativada por padrão em iframes de origem cruzada, principalmente por questões de segurança. Esta limitação significava que os programadores tinham de redirecionar os utilizadores ou usar janelas pop-up para [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys), o que resultava numa experiência de utilizador menos fluida. Em passkeys / WebAuthn, existem duas operações centrais (também chamadas de cerimónias): 1. Registar / criar uma passkey 2. Autenticar / fazer login com uma passkey As duas operações não tinham e não têm o mesmo suporte em iframes de origem cruzada: Inicialmente, o **login através de iframes de origem cruzada foi tornado possível**, mas a **criação de origem cruzada ainda não**, porque não havia ninguém com um caso de uso. Avanços recentes (por exemplo, no Chrome 123) **introduziram suporte para a criação de passkeys em iframes de origem cruzada** sob condições específicas. No entanto, em maio de 2024, nem todos os navegadores suportam totalmente a criação de passkeys através de iframes de origem cruzada, embora o login seja possível na maioria dos navegadores. Além disso, o suporte para iframes de origem cruzada (para operações de registo e [autenticação](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys)) já está incorporado na especificação [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) em desenvolvimento. Alguns navegadores ainda precisam de se atualizar para a especificação (por exemplo, o Safari). Infelizmente, a Apple ainda não anunciou se e quando permitirá o registo de origem cruzada de passkeys no Safari. Isso removeria a limitação técnica mais significativa para o uso de passkeys em iframes de origem cruzada. Nas secções seguintes do artigo, assumimos o uso de iframes de origem cruzada. ### 3.1 Login com Passkeys em iframes de Origem Cruzada As tabelas seguintes fornecem uma visão geral do suporte de navegadores/padrões para autenticação em iframes e login via passkeys em contextos de iframe de origem cruzada: | **Navegador/Padrão** | **Contexto Primário (First-Party)** | **Contexto de Terceiros (Third-Party)** | | --------------------------- | ----------------------------------- | --------------------------------------- | | Exigido no WebAuthn Level 2 | ✔️ | ✔️ | | Exigido no WebAuthn Level 3 | ✔️ | ✔️ | | Implementado no Chrome | ✔️ | ✔️ | | Implementado no Firefox | ✔️ | ✔️ | | Implementado no Safari | ✔️ | ✔️ | ### 3.2 Criar Passkeys em iframes de Origem Cruzada Em maio de 2024, a criação de uma passkey num iframe de origem cruzada ainda não é possível em todos os navegadores. A tabela seguinte fornece uma visão geral do suporte de navegadores/padrões para o registo/criação de passkeys em iframes de origem cruzada: | **Navegador/Padrão** | **Contexto Primário (First-Party)** | **Contexto de Terceiros (Third-Party)** | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------ | | Exigido no WebAuthn Level 2 | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ❌ | | Exigido no WebAuthn Level 3 | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | | Implementado no Chrome | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | | Implementado no Firefox | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | ✔️ [Detalhes](https://github.com/mozilla/standards-positions/issues/964) | | Implementado no [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Detalhes](https://issues.chromium.org/issues/40258856) | Aguardando sinal para implementação | Se estiver interessado em mais detalhes sobre este desenvolvimento e suporte, recomendamos que consulte esta [issue do GitHub](https://github.com/w3c/webauthn/issues/1656) e este [Pull Request](https://github.com/w3c/webauthn/pull/1801). ### 3.3 Casos de Uso para Passkeys em iframes Existem dois grandes casos de uso para suportar passkeys em iframes de origem cruzada. #### 3.3.1 Identidade Federada Permitir passkeys em iframes de origem cruzada é crucial para cenários de identidade federada onde múltiplos [domínios](https://www.corbado.com/pt/blog/webauthn-relying-party-id-rpid-passkeys) estão envolvidos, mas as mesmas contas de utilizador devem ser usadas. Vamos considerar o seguinte cenário. Você é uma empresa multinacional como a [KAYAK](https://www.corbado.com/blog/kayak-passkeys) e tem diferentes domínios para diferentes regiões: - [www.kayak.com](https://www.kayak.com) - [www.kayak.us](https://www.kayak.us) - [www.kayak.de](https://www.kayak.de) No entanto, você tem um sistema central de gestão de identidade que permite aos utilizadores fazerem login com a mesma conta e credenciais em todos esses domínios. O padrão WebAuthn representaria um desafio para estes cenários, uma vez que as passkeys só podem ser vinculadas a um único domínio (ID da [Relying Party](https://www.corbado.com/glossary/relying-party)), por exemplo, [www.kayak.com](http://www.kayak.com). Para superar este desafio, você usaria um iframe da origem [www.kayak.com](https://www.kayak.com) em todos os seus outros domínios. Assim, você incorpora um iframe com a origem [www.kayak.com](https://www.kayak.com) em [www.kayak.us](https://www.kayak.us) e em [www.kayak.de](https://www.kayak.de) (iframe de origem cruzada). Caso contrário, o uso das suas passkeys vinculadas a “[www.kayak.com](https://www.kayak.com)” nestes outros domínios não seria possível devido à resistência ao [phishing](https://www.corbado.com/glossary/phishing) das passkeys. Nota lateral: A nova funcionalidade do WebAuthn de [Related Origin Requests (RoR)](https://passkeys.dev/docs/advanced/related-origins/) também poderia ser usada como alternativa. Esta funcionalidade permite que “origens relacionadas” acedam a passkeys sem iframes, mas ainda não há suporte em todos os navegadores. #### 3.3.2 Pagamentos Também para fluxos de [pagamento](https://www.corbado.com/passkeys-for-payment) fluidos, o uso de passkeys em iframes de origem cruzada desempenha um papel importante. Considere o seguinte cenário: um cliente quer comprar sapatos novos no site de um comerciante (por exemplo, [www.amazon.com](http://www.amazon.com)). O site deste comerciante permite que o cliente pague através da sua conta bancária (por exemplo, em [www.revolut.com](http://www.revolut.com)) e, para isso, exige que o utilizador faça login no site do banco (este é um processo simplificado). O utilizador faz login no site do banco com uma passkey que está vinculada ao ID da [Relying Party](https://www.corbado.com/glossary/relying-party) do banco, por exemplo, “[revolut](https://www.corbado.com/blog/revolut-passkeys).com”. Para evitar redirecionar o utilizador do site do comerciante ([www.amazon.com](https://www.amazon.com)) para o site do banco ([www.revolut.com](https://www.revolut.com)) no processo de checkout e permitir que o utilizador faça login na sua conta bancária, pode ser usado um iframe de origem cruzada. Desta forma, o utilizador permanece em [www.amazon.com](https://www.amazon.com) e usa a passkey no iframe de origem cruzada para a autenticação que criou para [www.revolut.com](https://www.revolut.com). Assim, a integração de passkeys através de iframes de origem cruzada em fluxos de [pagamento](https://www.corbado.com/passkeys-for-payment) garante transações seguras e simplificadas entre consumidores, comerciantes e bancos: | **Consumidores** | **Comerciantes** | **Bancos** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | | No contexto de [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) e passkeys, também recomendamos que dê uma olhada no nosso artigo sobre [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) e [dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) com passkeys. Certifique-se também de verificar as limitações para o contexto de terceiros em [Aplicações Nativas](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) abaixo. Adicionalmente, para uma visão mais aprofundada dos fluxos de pagamento de origem cruzada usando passkeys, consulte o nosso artigo Passkeys para Fornecedores de Pagamento: Como Construir um SDK de Terceiros. ## 4. Benefícios de Usar Passkeys em iframes Em geral, a integração de passkeys em iframes oferece vários benefícios, principalmente ao melhorar a UX e a segurança. Aqui está um detalhe dessas vantagens: **Experiência do Utilizador Melhorada** 1. **Sem Pop-ups ou Redirecionamentos:** Os utilizadores podem autenticar-se diretamente no conteúdo incorporado sem redirecionamentos ou pop-ups, resultando numa experiência mais fluida e menos disruptiva. 2. **UX Consistente Entre Sites:** Incorporar fluxos de autenticação em iframes garante uma experiência de utilizador consistente em diferentes secções de um website ou entre diferentes websites que usam o mesmo serviço de autenticação. **Segurança Melhorada** 1. **Transações Seguras:** Para cenários como [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos), as passkeys em iframes aumentam a segurança das transações, garantindo que a autenticação ocorra num contexto seguro e incorporado. 2. **Uso da Conta de Utilizador em Diferentes Websites:** Em configurações de identidade federada, as passkeys em iframes de origem cruzada permitem uma verificação de identidade segura e eficiente em múltiplos domínios. ## 5. Guia Passo a Passo para Implementar Passkeys em iframes A implementação de passkeys em iframes envolve alguns passos chave para garantir a segurança e a funcionalidade. Fornecemos um guia detalhado para programadores. Por favor, veja também o exemplo de implementação em [https://cross-origin-iframe.vercel.app/](https://cross-origin-iframe.vercel.app/). ![Cross-Origin iframe Passkey Demo](https://www.corbado.com/website-assets/cross_origin_iframe_passkey_demo_8879588a51.png) ### 5.1 Definir a Política de Permissões para publickey-credentials-get e publickey-credentials-create O cabeçalho HTTP `Permissions-Policy` ajuda a permitir ou negar o uso de certas funcionalidades do navegador num documento ou dentro de um elemento iframe. Para ativar logins com passkey num iframe, deve definir as **políticas de permissão** [publickey-credentials-get](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get) e [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-create). As políticas permitem que o conteúdo incorporado invoque o método da API WebAuthn necessário para autenticar (`navigator.credentials.get({publicKey})`) e criar uma passkey (`navigator.credentials.create({publicKey})`). `` A `Permissions Policy` HTTP era anteriormente chamada de `Feature Policy`. Sob a `Feature Policy`, podia conceder uma funcionalidade a um iframe de origem cruzada adicionando a origem à lista de origens do cabeçalho ou incluindo um atributo `allow` na tag do iframe. Com a `Permissions Policy`, adicionar um frame de origem cruzada à lista de origens requer que a tag do iframe para essa origem inclua o atributo `allow`. Se a resposta não tiver um cabeçalho `Permissions Policy`, a lista de origens assume o valor padrão `*` (todas as origens). Incluir o atributo `allow` no iframe concede acesso à funcionalidade. Para garantir que iframes de origem cruzada não especificados na lista de origens sejam impedidos de aceder à funcionalidade, mesmo que o atributo `allow` esteja presente, os programadores podem definir explicitamente o cabeçalho `Permissions Policy` na resposta. No Chrome 88+, a `Feature Policy` ainda pode ser usada, mas atua como um alias para a `Permissions Policy`. Além das diferenças de sintaxe, a lógica permanece a mesma. Quando os cabeçalhos `Permissions Policy` e `Feature Policy` são usados simultaneamente, o cabeçalho `Permissions Policy` tem precedência e substituirá o valor definido pelo cabeçalho `Feature Policy`. Por favor, veja também este [artigo do blogue da equipa do Chrome](https://developer.chrome.com/docs/privacy-security/permissions-policy) para mais detalhes de implementação. ### 5.2 Configurar Cabeçalhos HTTP Garanta que os cabeçalhos de resposta HTTP do URL de origem do iframe incluem a ´[Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe)\` relevante. Isto é crucial para o suporte de origem cruzada. `Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*` Para um controlo mais granular, pode especificar origens particulares permitidas para incorporar o conteúdo do iframe. `Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")` ### 5.3 Gerir a Ativação do Utilizador Garanta que o conteúdo do iframe requer uma ação do utilizador para acionar a autenticação com passkey. Isto pode ser feito usando event listeners para cliques ou submissões de formulários dentro do iframe. Este processo também é chamado de [transient activation](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) = { /* Configuration options */ }; const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions}); // Handle the created credential } catch (err) { console.error('Error authenticating via passkey:', err); } }); ``` Neste contexto, veja também o nosso artigo do blogue sobre os requisitos de gestos do utilizador no Safari. ### 5.4 Exemplo de Implementação A seguir, encontra um trecho de código de exemplo completo de um ficheiro `index.html` alojado em [https://cross-origin-iframe.vercel.com](https://cross-origin-iframe.vercel.com) que usa um iframe de origem cruzada para passkeys através de [https://passkeys.eu](https://passkeys.eu). ```html Cross-Origin iframe with Passkeys Demo

Cross-Origin iframe with Passkeys Demo

``` ## 6. Desafios Comuns e Como Superá-los A implementação de passkeys em iframes pode trazer um conjunto de desafios que os programadores precisam de resolver para garantir uma experiência de utilizador fluida e segura. Aqui está uma análise detalhada dos desafios comuns e como superá-los. ### 6.1 Desafio 1: Configuração da Política de Permissões **Problema:** Configurar incorretamente as políticas de permissão pode impedir que o iframe aceda às APIs 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.”** Se não adicionar as políticas de permissão corretamente, o navegador lançará o seguinte erro: ![passkey iframe permission policy configuration](https://www.corbado.com/website-assets/passkey_iframe_permission_policy_configuration_4819cbebec.png) **Solução:** - **Verifique Duplamente se o Atributo `allow` e os Cabeçalhos HTTP Estão Definidos**: Garanta que o atributo `allow` e os cabeçalhos HTTP estão corretamente definidos. Verifique duplamente se as permissões `publickey-credentials-get` e `publickey-credentials-create` estão incluídas tanto no elemento iframe como nos cabeçalhos de resposta HTTP do servidor. - **Cabeçalhos Meta em Vez de Cabeçalhos do Servidor Web:** Use cabeçalhos `` para definir as políticas de permissão em vez de definir os cabeçalhos no seu servidor web. - **Ponto e Vírgula em Vez de Vírgula na Permissions-Policy:** Anteriormente, a `Permissions-Policy` era chamada de `Feature-Policy`. Elementos individuais de uma `Feature-Policy` eram separados por uma vírgula em vez de um ponto e vírgula (que é o padrão para a `Permissions-Policy`). A `Permissions-Policy` do iframe ainda segue a sintaxe da `Feature-Policy` e, portanto, usa vírgulas. Os atributos sandbox / `allow` ainda são separados por um ponto e vírgula (veja o trecho de código acima). **Dica:** Para testar adequadamente se os seus cabeçalhos `Permission-Policy` estão definidos corretamente, recomendamos abrir as ferramentas de programador do seu navegador, aceder a **Aplicação** (aqui: nas ferramentas de programador do Chrome), ir para **Frames** e procurar a origem do iframe (aqui: passkeys.eu/). Se a `Permissions-Policy` estiver definida corretamente, `publickey-credential-create` e `publickey-credential-get` devem estar listados entre as **Funcionalidades Permitidas**: ![passkey permissions policy allowed features](https://www.corbado.com/website-assets/passkey_permissions_policy_allowed_features_ffadbc4302.png) ### 6.2 Desafio 2: Problemas com iframes de Origem Cruzada no Safari **Problema:** A criação de passkey ou o login com passkey no iframe de origem cruzada não funciona, e vê o seguinte erro na consola do seu navegador. **"NotAllowedError - The origin of the document is not the same as its ancestors."** Este erro aparece ao usar o navegador Safari e tentar criar uma passkey de dentro do iframe, pois o Safari não suporta a criação de passkey em iframes de origem cruzada (ver acima). ![passkey iframe not allowed error](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png) **Solução:** Aqui, não há muito que possa fazer, pois o Safari ainda não suporta a criação de uma passkey de dentro de um iframe de origem cruzada (ainda). **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.** Este erro não está diretamente ligado a passkeys, mas sim a iframes de origem cruzada no Safari em geral. Como parte da [iniciativa do Safari / WebKit para bloquear cookies de terceiros](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) ou o acesso ao LocalStorage num contexto de terceiros, partes da lógica JavaScript podem estar quebradas. ![passkey iframe third party cookie](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png) **Solução:** Aqui, precisa de garantir que não está a usar cookies de terceiros dentro dos seus iframes, pois isso causa um erro. ### 6.3 Desafio 3: Compatibilidade de Navegadores **Problema:** Problemas de compatibilidade de navegadores com iframes surgem quando diferentes navegadores têm níveis variados de suporte para WebAuthn, permissões de iframe e atributos de segurança, levando a um comportamento inconsistente. **Solução:** Para mitigar estes problemas de compatibilidade de navegadores com iframes, teste a implementação em múltiplos navegadores para garantir a compatibilidade e identificar quaisquer problemas específicos do navegador. **Passos:** 1. Realize testes entre navegadores usando ferramentas como BrowserStack ou Sauce Labs. 2. Resolva quaisquer discrepâncias implementando correções ou fallbacks específicos para cada navegador. ### 6.4 Desafio 4: iframes em Aplicações Nativas **Problema:** Ao usar iframes que requerem passkeys dentro de [aplicações nativas](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas), uma distinção crucial deve ser feita entre contextos **primários (first-party)** e **de terceiros (third-party)**: - **Contexto primário**: As passkeys estão vinculadas ao mesmo domínio da empresa que executa a aplicação. Por exemplo, uma aplicação de [e-commerce](https://www.corbado.com/passkeys-for-e-commerce) que depende do seu próprio domínio para a autenticação do utilizador. - **Contexto de terceiros**: Um domínio diferente (por exemplo, um fornecedor de [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) ou um provedor de identidade) lida com o fluxo de criação de passkey ou login. Num **WebView incorporado (EWV)**, como o [WKWebView](https://www.corbado.com/blog/native-app-passkeys) no [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ou um [WebView](https://www.corbado.com/blog/native-app-passkeys) do [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) - a aplicação que o chama tem um controlo extensivo sobre a sessão web (por exemplo, intercetando pedidos). Esta configuração normalmente suporta passkeys apenas se o domínio da passkey (o ID da [Relying Party](https://www.corbado.com/glossary/relying-party)) corresponder ao domínio da aplicação (primário). No entanto, num cenário de terceiros - como um fluxo de origem cruzada de um fornecedor de pagamentos - um [WebView](https://www.corbado.com/blog/native-app-passkeys) incorporado geralmente não consegue aceder às credenciais de passkey necessárias porque a aplicação do comerciante e o serviço do fornecedor de pagamentos são de origens diferentes. As “ligações” (bindings) necessárias para as passkeys (entre domínio, credencial e origem) não corresponderão no contexto incorporado. Esta limitação leva muitas aplicações a adotar uma abordagem de **WebView do sistema** (por exemplo, [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) no [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ou Custom Tabs no [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)). Os WebViews do sistema isolam o site de terceiros (por exemplo, o fornecedor de pagamentos) num ambiente seguro, semelhante a um navegador, que permite corretamente passkeys de origem cruzada — se o próprio navegador o suportar. No entanto, lembre-se que as **limitações existentes do iframe do Safari** também se aplicam ao [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys), portanto, se o Safari não permitir certas operações de passkey em iframes de terceiros, o mesmo acontecerá no [WebView](https://www.corbado.com/blog/native-app-passkeys) do sistema. Atualmente, não existe uma correção “nativa”; a melhor prática para **fluxos complexos** - como checkouts envolvendo fornecedores de pagamento externos - é abrir um WebView do sistema em vez de um incorporado. **Solução:** Para fornecedores de pagamento (e outros terceiros que dependem de passkeys entre domínios), planeie cuidadosamente a integração para garantir que o utilizador seja retirado de um WebView incorporado e levado para um do sistema. Embora seja uma experiência menos fluida do que um fluxo puramente incorporado, é muitas vezes a única maneira de garantir que a funcionalidade de passkey funcionará com serviços de terceiros. Para mais detalhes sobre como lidar com passkeys de terceiros em [aplicações nativas](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) e WebViews, consulte Passkeys para Fornecedores de Pagamento: SDK de Pagamento com Passkeys de Terceiros. ## 7. Nota Adicional para Fornecedores de Pagamento: iframes de Origem Cruzada e SDKs de Terceiros Embora os tópicos discutidos acima se apliquem a vários cenários, são **particularmente importantes para fornecedores de pagamento**, onde fluxos multi-domínio (por exemplo, site do comerciante e gateway de pagamento) devem incorporar a autenticação do utilizador em **iframes de origem cruzada**. Nestas configurações: - **Utilizadores** querem um checkout na página, sem atritos e sem pop-ups de redirecionamento. - **Fornecedores de pagamento** devem lidar com o registo ou login com passkey no seu próprio domínio (por exemplo, `pay.provider.com`), mesmo que estejam incorporados no site de um comerciante. - As **restrições do Safari** e as limitações do **WebView incorporado** frequentemente bloqueiam a criação de passkeys de terceiros em iframes. Para enfrentar estes desafios e construir uma experiência segura e fluida, semelhante ao **Apple Pay**, os fornecedores de pagamento adotam frequentemente uma **abordagem híbrida** - combinando a integração baseada em iframe com um [fallback](https://www.corbado.com/pt/faq/login-segundo-dispositivo-chave-de-acesso-vinculada) de redirecionamento para o Safari (ou navegadores mais antigos). Em alguns casos, os fluxos de **navegador do sistema** (por exemplo, [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) no [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)) tornam-se obrigatórios se um WebView incorporado não permitir passkeys de todo. Para um **mergulho profundo** nestes cenários específicos de pagamento - incluindo comparações entre **iframe vs. redirecionamento**, considerações sobre **aplicações nativas** e melhores práticas para uma alta adoção de passkeys, consulte o nosso artigo dedicado: Em particular: - [**Estratégia A: Incorporar um iframe de Origem Cruzada**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#51-strategy-a-embedding-a-cross-origin-iframe-pros--cons) explica como lidar com a criação e login de passkeys em linha, referenciando as configurações de `Permissions-Policy` aqui introduzidas. - [**Estratégia B: Abordagem Baseada em Redirecionamento**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#52-strategy-b-redirect-based-approach-for-broader-compatibility) mostra uma integração mais simples que contorna a maioria das armadilhas de origem cruzada, embora ao [custo](https://www.corbado.com/pt/blog/custos-sms) de sair do domínio do comerciante. - [**WebView do Sistema**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#63-using-system-webview-or-redirect-for-third-party-passkeys) é essencial para aplicações nativas, pois os WebViews incorporados frequentemente quebram os fluxos de passkeys de terceiros. Este guia complementar fornece **estratégias aprofundadas** para proteger transações, superar as restrições de origem cruzada do Safari e otimizar o uso de passkeys em contextos de terceiros. Ao combinar os passos técnicos deste artigo com esses métodos focados em pagamentos, pode oferecer um fluxo de checkout sem atritos e resistente a [phishing](https://www.corbado.com/glossary/phishing) diretamente dentro de um iframe, desbloqueando o próximo nível de segurança e UX para pagamentos online. ## 8. Conclusão A integração de passkeys em iframes melhora significativamente a autenticação do utilizador, aumentando tanto a segurança como a experiência do utilizador. Isto permite uma autenticação fluida sem a necessidade de redirecionamentos ou pop-ups, garantindo uma UX consistente em várias secções e sites. Implementações do mundo real, como a [integração de passkeys pela Shopify](https://shopify.engineering/supporting-passkeys-in-shop-authentication-flows) no seu componente de login, demonstram os benefícios práticos e a flexibilidade desta abordagem.