Passkeys e iframes: como criar e fazer login com uma passkey?

Legenda
✅ = suportado ❌ = não suportado

Semana após semana, cada vez mais organizações anunciam a implementação de passkeys (por exemplo, recentemente a Visa, a Mastercard ou a Vercel). À 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 e às interações do utilizador.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

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.

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.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

O iframe básico é o tipo mais comummente utilizado. Ele simplesmente incorpora conteúdo de outro URL dentro da página atual.

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

Este iframe básico é frequentemente usado para incluir conteúdo estático, como um artigo, dentro de uma página web.

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.

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

As media queries de CSS também podem ser usadas para fazer o iframe ajustar-se dinamicamente com base no tamanho da viewport.

Get a free passkey assessment in 15 minutes.

Book free consultation

Um iframe seguro ou em sandbox restringe as ações que podem ser executadas dentro do iframe. Isso é útil para incorporar conteúdo de fontes não confiáveis ou para aumentar a segurança.

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

O atributo sandbox pode incluir várias restrições, tais como:

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

O atributo sandbox permite que scripts sejam executados, mas restringe ações potencialmente perigosas, como submissões de formulários ou uso de plugins.

Become part of our Passkeys Community for updates & support.

Join

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 ou widgets de redes sociais. Devido a restrições de segurança, 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 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.

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.

As empresas confiam na Corbado para proteger os seus utilizadores e tornar os logins mais fluidos com passkeys. Obtenha já a sua consulta gratuita sobre passkeys.

Obtenha uma consulta gratuita

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 numa página web alojada em https://www.mystore.com. Estas são de origem cruzada porque têm domínios diferentes.

Exemplo de mesma origem:

Incorporar conteúdo de https://www.example.com/shop numa página web alojada em 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.

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

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 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, 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) já está incorporado na especificação WebAuthn Level 3 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.

Want to find out how many people use passkeys?

View Adoption Data

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:

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:

Se estiver interessado em mais detalhes sobre este desenvolvimento e suporte, recomendamos que consulte esta issue do GitHub e este Pull Request.

Existem dois grandes casos de uso para suportar passkeys em iframes de origem cruzada.

Permitir passkeys em iframes de origem cruzada é crucial para cenários de identidade federada onde múltiplos domínios 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 e tem diferentes domínios para diferentes regiões:

• www.kayak.com
• www.kayak.us
• 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), por exemplo, www.kayak.com.

Para superar este desafio, você usaria um iframe da origem www.kayak.com em todos os seus outros domínios. Assim, você incorpora um iframe com a origem www.kayak.com em www.kayak.us e em www.kayak.de (iframe de origem cruzada). Caso contrário, o uso das suas passkeys vinculadas a “www.kayak.com” nestes outros domínios não seria possível devido à resistência ao phishing das passkeys.

Nota lateral: A nova funcionalidade do WebAuthn de Related Origin Requests (RoR) 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.

Também para fluxos de pagamento 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). O site deste comerciante permite que o cliente pague através da sua conta bancária (por exemplo, em 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 do banco, por exemplo, “revolut.com”.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Para evitar redirecionar o utilizador do site do comerciante (www.amazon.com) para o site do banco (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 e usa a passkey no iframe de origem cruzada para a autenticação que criou para www.revolut.com.

Assim, a integração de passkeys através de iframes de origem cruzada em fluxos de pagamento garante transações seguras e simplificadas entre consumidores, comerciantes e bancos:

No contexto de pagamentos e passkeys, também recomendamos que dê uma olhada no nosso artigo sobre Secure Payment Confirmation (SPC) e dynamic linking com passkeys. Certifique-se também de verificar as limitações para o contexto de terceiros em Aplicações 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.

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, 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.

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/.

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 e 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})).

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

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 para mais detalhes de implementação.

Garanta que os cabeçalhos de resposta HTTP do URL de origem do iframe incluem a ´Permissions-Policy` 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")

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.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/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.

A seguir, encontra um trecho de código de exemplo completo de um ficheiro index.html alojado em https://cross-origin-iframe.vercel.com que usa um iframe de origem cruzada para passkeys através de 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>Cross-Origin iframe with Passkeys Demo</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>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

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.

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:

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 <meta/> 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:

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).

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" from accessing a frame with origin "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 ou o acesso ao LocalStorage num contexto de terceiros, partes da lógica JavaScript podem estar quebradas.

Solução: Aqui, precisa de garantir que não está a usar cookies de terceiros dentro dos seus iframes, pois isso causa um erro.

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.

Problema: Ao usar iframes que requerem passkeys dentro de aplicações 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 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 ou um provedor de identidade) lida com o fluxo de criação de passkey ou login.

Num WebView incorporado (EWV), como o WKWebView no iOS ou um WebView do 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) 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 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 no iOS ou Custom Tabs no 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, portanto, se o Safari não permitir certas operações de passkey em iframes de terceiros, o mesmo acontecerá no WebView 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.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Para mais detalhes sobre como lidar com passkeys de terceiros em aplicações nativas e WebViews, consulte Passkeys para Fornecedores de Pagamento: SDK de Pagamento com Passkeys 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 de redirecionamento para o Safari (ou navegadores mais antigos). Em alguns casos, os fluxos de navegador do sistema (por exemplo, ASWebAuthenticationSession no 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:

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

Get free Whitepaper

Em particular:

• Estratégia A: Incorporar um iframe de Origem Cruzada 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 mostra uma integração mais simples que contorna a maioria das armadilhas de origem cruzada, embora ao custo de sair do domínio do comerciante.
• WebView do Sistema é 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 diretamente dentro de um iframe, desbloqueando o próximo nível de segurança e UX para pagamentos online.

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 no seu componente de login, demonstram os benefícios práticos e a flexibilidade desta abordagem.