Passkeys e iframes: ¿Cómo crear e iniciar sesión con una passkey?

Leyenda
✅ = soportado ❌ = no soportado

Semana tras semana, más y más organizaciones anuncian sus lanzamientos de passkeys (por ejemplo, últimamente Visa, Mastercard o Vercel). A medida que los desarrolladores y gerentes de producto de otras empresas siguen estos modelos, se discuten más casos de uso para la implementación de passkeys.

Un caso por el que nos preguntan constantemente es cómo funcionan las passkeys en iframes, ya que los iframes se utilizan ampliamente en el desarrollo web moderno para incrustar contenido de diferentes fuentes sin problemas. En el contexto de las passkeys y WebAuthn, los iframes presentan su propio conjunto de desafíos, especialmente en lo que respecta a la seguridad y las interacciones del usuario.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Esta publicación de blog ofrece una guía completa sobre el uso de passkeys y WebAuthn en iframes. Nosotros vamos a:

• Explorar las capacidades actuales
• Analizar el soporte de iframes de origen cruzado
• Destacar los beneficios de la integración de iframes y
• Proporcionar una guía de implementación paso a paso

Al final de esta publicación, tendremos una comprensión clara de cómo aprovechar las passkeys dentro de los iframes.

Los iframes, o marcos en línea, son elementos HTML que permiten a los desarrolladores incrustar otro documento HTML dentro del documento actual. Esta capacidad se utiliza ampliamente para incorporar contenido de fuentes externas, como videos, mapas y otras páginas web, en un sitio web.

Echemos un vistazo a los diferentes tipos de iframes.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

El iframe básico es el tipo más utilizado. Simplemente incrusta contenido de otra URL dentro de la página actual.

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

Este iframe básico se utiliza a menudo para incluir contenido estático, como un artículo, dentro de una página web.

Los iframes responsivos están diseñados para ajustar su tamaño según el tamaño de la pantalla o el contenedor en el que se encuentran. Esto asegura que el contenido incrustado se vea bien en todos los dispositivos, incluidos ordenadores de escritorio, tabletas y teléfonos móviles.

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

También se pueden usar media queries de CSS para hacer que el iframe se ajuste dinámicamente según el tamaño del viewport.

Get a free passkey assessment in 15 minutes.

Book free consultation

Un iframe seguro o en modo sandbox restringe las acciones que se pueden realizar dentro del iframe. Esto es útil para incrustar contenido de fuentes no confiables o para mejorar la seguridad.

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

El atributo sandbox puede incluir varias restricciones, como:

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

El atributo sandbox permite que se ejecuten scripts pero restringe acciones potencialmente peligrosas, como el envío de formularios o el uso de plugins.

Become part of our Passkeys Community for updates & support.

Join

Los iframes de origen cruzado incrustan contenido de un dominio diferente. Se utilizan comúnmente para integrar servicios de terceros, como pasarelas de pago o widgets de redes sociales. Debido a restricciones de seguridad, estos iframes tienen acceso limitado al contenido de la página que los incrusta y viceversa.

Origen cruzado significa que el contenido que se carga proviene de un origen diferente, donde un origen se define por la combinación del esquema (protocolo), el host (dominio) y el número de puerto. Por ejemplo, https://example.com y http://example.com se consideran orígenes diferentes porque usan esquemas diferentes (HTTP vs. HTTPS).

Del mismo modo, los subdominios se tratan como orígenes separados de sus dominios principales. Por ejemplo, https://example.com y https://sub.example.com son de origen cruzado, aunque compartan el mismo dominio base. Esta separación garantiza que los scripts y los datos de un subdominio no puedan interactuar directamente con los de otro sin un permiso explícito, mejorando la seguridad.

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.

Las empresas confían en Corbado para proteger a sus usuarios y hacer que los inicios de sesión sean más fluidos con passkeys. Obtén tu consulta gratuita sobre passkeys ahora.

Obtener consulta gratuita

Aquí hay ejemplos para ilustrar los conceptos de origen cruzado y mismo origen:

Ejemplo de origen cruzado:

Incrustar contenido de https://payment.example.com en una página web alojada en https://www.mystore.com. Estos son de origen cruzado porque tienen dominios diferentes.

Ejemplo del mismo origen:

Incrustar contenido de https://www.example.com/shop en una página web alojada en https://www.example.com/blog. Estos son del mismo origen porque comparten el mismo esquema, host y puerto.

Los iframes de origen cruzado se diferencian de los iframes básicos en que la fuente proviene de otro dominio, mientras que un iframe del mismo sitio tiene su fuente en el mismo dominio donde está incrustado.

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

El uso de passkeys en iframes introduce nuevas capacidades y restricciones que los desarrolladores deben comprender, principalmente en torno al establecimiento de los permisos correctos y la garantía de interacciones seguras del usuario dentro del contexto incrustado.

Históricamente, la API de Autenticación Web (WebAuthn) estaba deshabilitada por defecto en iframes de origen cruzado, principalmente por motivos de seguridad. Esta limitación significaba que los desarrolladores tenían que redirigir a los usuarios o usar ventanas emergentes para la autenticación, lo que resultaba en una experiencia de usuario menos fluida.

En passkeys / WebAuthn, hay dos operaciones principales (también llamadas ceremonias):

1. Registrar / crear una passkey
2. Autenticar / iniciar sesión con una passkey

Las dos operaciones no tuvieron ni tienen el mismo soporte en iframes de origen cruzado:

Al principio, se hizo posible el inicio de sesión a través de iframes de origen cruzado, pero la creación de origen cruzado aún no, porque no había nadie con un caso de uso.

Avances recientes (por ejemplo, en Chrome 123) han introducido soporte para la creación de passkeys en iframes de origen cruzado bajo condiciones específicas. Sin embargo, a fecha de mayo de 2024, no todos los navegadores soportan completamente la creación de passkeys a través de iframes de origen cruzado, aunque el inicio de sesión es posible con la mayoría de los navegadores.

Además, el soporte de iframes de origen cruzado (para operaciones de registro y autenticación) ya está incorporado en la especificación en curso de WebAuthn Nivel 3. Algunos navegadores aún necesitan ponerse al día con la especificación (por ejemplo, Safari). Lamentablemente, Apple aún no ha anunciado si permitirá el registro de passkeys de origen cruzado en Safari ni cuándo lo hará. Esto eliminaría la limitación técnica más significativa para usar passkeys en iframes de origen cruzado.

En las siguientes partes de la publicación del blog, asumimos el uso de iframes de origen cruzado.

Want to find out how many people use passkeys?

View Adoption Data

Las siguientes tablas proporcionan una descripción general del soporte de navegadores/estándares para la autenticación en iframes y el inicio de sesión con passkeys en contextos de iframes de origen cruzado:

A fecha de mayo de 2024, la creación de una passkey en un iframe de origen cruzado aún no es posible en todos los navegadores. La siguiente tabla proporciona una descripción general del soporte de navegadores/estándares para el registro / creación de passkeys en iframes de origen cruzado:

Si te interesa conocer más detalles sobre este desarrollo y soporte, te recomendamos echar un vistazo a este issue de GitHub y a este Pull Request.

Hay dos casos de uso principales para soportar passkeys en iframes de origen cruzado.

Habilitar passkeys en iframes de origen cruzado es crucial para escenarios de identidad federada donde intervienen múltiples dominios pero se deben usar las mismas cuentas de usuario.

Tomemos el siguiente escenario. Eres una empresa multinacional como KAYAK y tienes diferentes dominios para diferentes regiones:

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

Sin embargo, tienes un sistema central de gestión de identidades que permite a los usuarios iniciar sesión con la misma cuenta y credenciales en todos estos dominios. El estándar WebAuthn plantearía un desafío para estos escenarios, ya que las passkeys solo pueden vincularse a un dominio (ID de Relying Party), por ejemplo, www.kayak.com.

Para superar este desafío, se usaría un iframe del origen www.kayak.com en todos tus otros dominios. Así que incrustas un iframe con el origen www.kayak.com en www.kayak.us y en www.kayak.de (iframe de origen cruzado). De lo contrario, el uso de tus passkeys vinculadas a "www.kayak.com" en estos otros dominios no sería posible debido a la resistencia al phishing de las passkeys.

Nota al margen: También se podría usar alternativamente la nueva función de WebAuthn de Solicitudes de Origen Relacionado (RoR). Esta función permite que los "orígenes relacionados" accedan a las passkeys sin iframes, pero aún no es compatible con todos los navegadores.

También para flujos de pago fluidos, el uso de passkeys en iframes de origen cruzado juega un papel importante. Considera el siguiente escenario: Un cliente quiere comprar zapatos nuevos en el sitio web de un comerciante (por ejemplo, www.amazon.com). El sitio web de este comerciante permite al cliente pagar a través de su cuenta bancaria (por ejemplo, en www.revolut.com) y, por lo tanto, requiere que el usuario inicie sesión en el sitio web del banco (este es un proceso simplificado). El usuario inicia sesión en el sitio web del banco con una passkey que está vinculada al ID de Relying Party del banco, por ejemplo, "revolut.com".

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Para evitar redirigir al usuario desde el sitio web del comerciante (www.amazon.com) al sitio web del banco (www.revolut.com) en el proceso de pago y permitir que el usuario inicie sesión allí en la cuenta del banco, se puede usar un iframe de origen cruzado. De esta manera, el usuario permanece en www.amazon.com y usa la passkey en el iframe de origen cruzado para la autenticación que creó para www.revolut.com.

Por lo tanto, la integración de passkeys a través de iframes de origen cruzado en los flujos de pago garantiza transacciones seguras y optimizadas entre consumidores, comerciantes y bancos:

En el contexto de los pagos y las passkeys, también recomendamos echar un vistazo a nuestra publicación de blog sobre la Confirmación de Pago Segura (SPC) y el enlace dinámico con passkeys. Asegúrate también de revisar las limitaciones para el contexto de terceros en aplicaciones nativas a continuación.

Además, para una visión más profunda de los flujos de pago de origen cruzado usando passkeys, consulta nuestro artículo Passkeys para proveedores de pago: Cómo construir un SDK de terceros.

En general, la integración de passkeys en iframes ofrece varios beneficios, principalmente al mejorar la experiencia de usuario (UX) y la seguridad. Aquí hay un desglose de estas ventajas:

Experiencia de usuario mejorada

1. Sin ventanas emergentes ni redirecciones: Los usuarios pueden autenticarse directamente dentro del contenido incrustado sin redirecciones ni ventanas emergentes, lo que resulta en una experiencia más fluida y menos disruptiva.
2. UX consistente en todos los sitios: Incrustar flujos de autenticación dentro de iframes garantiza una experiencia de usuario consistente en diferentes secciones de un sitio web o en diferentes sitios web que utilizan el mismo servicio de autenticación.

Seguridad mejorada

1. Transacciones seguras: Para escenarios como los pagos, las passkeys en iframes mejoran la seguridad de las transacciones al garantizar que la autenticación ocurra dentro de un contexto seguro e incrustado.
2. Uso de la cuenta de usuario en diferentes sitios web: En configuraciones de identidad federada, las passkeys en iframes de origen cruzado permiten una verificación de identidad segura y eficiente en múltiples dominios.

La implementación de passkeys en iframes implica algunos pasos clave para garantizar la seguridad y la funcionalidad. Ofrecemos una guía detallada para desarrolladores. Consulta también la implementación de ejemplo en https://cross-origin-iframe.vercel.app/.

El encabezado HTTP Permissions-Policy ayuda a permitir o denegar el uso de ciertas funciones del navegador en un documento o dentro de un elemento iframe. Para habilitar los inicios de sesión con passkeys en un iframe, debes establecer las políticas de permisos publickey-credentials-get y publickey-credentials-create. Las políticas permiten que el contenido incrustado invoque el método necesario de la API de WebAuthn para autenticarse (navigator.credentials.get({publicKey})) y crear una passkey (navigator.credentials.create({publicKey})).

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

La Permissions Policy de HTTP se llamaba anteriormente Feature Policy. Bajo Feature Policy, podías otorgar una función a un iframe de origen cruzado ya sea agregando el origen a la lista de orígenes del encabezado o incluyendo un atributo allow en la etiqueta del iframe. Con Permissions Policy, agregar un marco de origen cruzado a la lista de orígenes requiere que la etiqueta del iframe para ese origen incluya el atributo allow. Si la respuesta carece de un encabezado Permissions Policy, la lista de orígenes por defecto es * (todos los orígenes). Incluir el atributo allow en el iframe otorga acceso a la función.

Para garantizar que los iframes de origen cruzado no especificados en la lista de orígenes sean bloqueados para acceder a la función, incluso si el atributo allow está presente, los desarrolladores pueden establecer explícitamente el encabezado Permissions Policy en la respuesta.

En Chrome 88+, Feature Policy todavía se puede usar, pero actúa como un alias para Permissions Policy. Aparte de las diferencias de sintaxis, la lógica sigue siendo la misma. Cuando se usan simultáneamente los encabezados Permissions Policy y Feature Policy, el encabezado Permissions Policy tiene prioridad y anulará el valor establecido por el encabezado Feature Policy. Consulta también esta publicación de blog del equipo de Chrome para más detalles de implementación.

Asegúrate de que los encabezados de respuesta HTTP de la URL de origen del iframe incluyan la ´Permissions-Policy´ relevante. Esto es crucial para el soporte de origen cruzado.

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

Para un control más granular, puedes especificar orígenes particulares permitidos para incrustar el contenido del iframe.

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

Asegúrate de que el contenido del iframe requiera una acción del usuario para activar la autenticación con passkey. Esto se puede hacer usando escuchas de eventos para clics o envíos de formularios dentro del iframe. Este proceso también se llama activación transitoria.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Opciones de configuración */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Manejar la credencial creada
        } catch (err) {
            console.error('Error al autenticar mediante passkey:', err);
        }
    });

En este contexto, consulta también nuestra publicación de blog sobre los requisitos de gestos de usuario de Safari.

A continuación, encontrarás un fragmento de código de ejemplo completo de un archivo index.html alojado en https://cross-origin-iframe.vercel.com que utiliza un iframe de origen cruzado para passkeys a travé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>Demostración de iframe de origen cruzado con Passkeys</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Demostración de iframe de origen cruzado con Passkeys</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

La implementación de passkeys en iframes puede presentar una serie de desafíos que los desarrolladores deben abordar para garantizar una experiencia de usuario fluida y segura. Aquí hay un vistazo detallado a los desafíos comunes y cómo superarlos.

Problema: Configurar incorrectamente las políticas de permisos puede impedir que el iframe acceda a las API de 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 no agregas las políticas de permisos correctamente, el navegador arrojará el siguiente error:

Solución:

• Verifica dos veces si el atributo Allow y los encabezados HTTP están configurados: Asegúrate de que el atributo allow y los encabezados HTTP estén configurados correctamente. Verifica dos veces que los permisos publickey-credentials-get y publickey-credentials-create estén incluidos tanto en el elemento iframe como en los encabezados de respuesta HTTP del servidor.
• Encabezados Meta en lugar de encabezados del servidor web: Usa encabezados <meta/> para definir las políticas de permisos en lugar de configurar los encabezados en tu servidor web.
• Punto y coma en lugar de coma en Permissions-Policy: Anteriormente, Permissions-Policy se llamaba Feature-Policy. Los elementos individuales de una Feature-Policy se separaban con una coma en lugar de un punto y coma (que es el estándar para Permissions-Policy). La Permissions-Policy del iframe sigue todavía la sintaxis de Feature-Policy y, por lo tanto, usa comas. Sin embargo, los atributos sandbox / allow todavía se separan con un punto y coma (ver el fragmento de código anterior).

Consejo: Para probar adecuadamente que tus encabezados Permission-Policy están configurados correctamente, recomendamos abrir las herramientas de desarrollador de tu navegador, acceder a Aplicación (aquí: en las herramientas de desarrollador de Chrome), ir a Marcos y buscar el origen del iframe (aquí: passkeys.eu/). Si la Permissions-Policy está configurada correctamente, publickey-credential-create y publickey-credential-get deberían aparecer entre las Características permitidas:

Problema: La creación de passkeys o el inicio de sesión con passkeys en iframes de origen cruzado no funciona, y ves el siguiente error en la consola de tu navegador.

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

Este error aparece cuando se usa el navegador Safari y se intenta crear una passkey desde dentro del iframe, ya que Safari no soporta la creación de passkeys en iframes de origen cruzado (ver arriba).

Solución: Aquí, realmente no puedes hacer nada, ya que Safari aún no soporta la creación de una passkey desde un iframe de origen cruzado (todavía).

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 error no está directamente relacionado con las passkeys, sino más bien con los iframes de origen cruzado en Safari en general. Como parte de la iniciativa de Safari / WebKit para bloquear las cookies de terceros o el acceso a LocalStorage en un contexto de terceros, partes de la lógica de JavaScript podrían estar rotas.

Solución: Aquí, debes asegurarte de no estar usando cookies de terceros dentro de tus iframes, ya que esto causa un error.

Problema: Los problemas de compatibilidad de iframes con los navegadores surgen cuando diferentes navegadores tienen niveles variables de soporte para WebAuthn, permisos de iframe y atributos de seguridad, lo que lleva a un comportamiento inconsistente.

Solución: Para mitigar estos problemas de compatibilidad de iframes con los navegadores, prueba la implementación en múltiples navegadores para garantizar la compatibilidad e identificar cualquier problema específico del navegador.

Pasos:

1. Realiza pruebas entre navegadores utilizando herramientas como BrowserStack o Sauce Labs.
2. Aborda cualquier discrepancia implementando correcciones o alternativas específicas para cada navegador.

Problema: Al usar iframes que requieren passkeys dentro de aplicaciones nativas, se debe hacer una distinción crucial entre los contextos de primera parte y tercera parte:

• Contexto de primera parte: Las passkeys están vinculadas al mismo dominio que la empresa que ejecuta la aplicación. Por ejemplo, una aplicación de comercio electrónico que depende de su propio dominio para la autenticación de usuarios.
• Contexto de tercera parte: Un dominio diferente (por ejemplo, un proveedor de pagos o un proveedor de identidad) maneja el flujo de creación de passkeys o inicio de sesión.

En un WebView incrustado (EWV) como WKWebView en iOS o un WebView de Android - la aplicación que llama tiene un control extenso sobre la sesión web (por ejemplo, interceptando solicitudes). Esta configuración generalmente soporta passkeys solo si el dominio de la passkey (el ID de Relying Party) coincide con el dominio de la aplicación (primera parte). Sin embargo, en un escenario de tercera parte - como el flujo de origen cruzado de un proveedor de pagos - un WebView incrustado generalmente no puede acceder a las credenciales de passkey necesarias porque la aplicación del comerciante y el servicio del proveedor de pagos son orígenes diferentes. Los "vínculos" requeridos para las passkeys (entre dominio, credencial y origen) no coincidirán en el contexto incrustado.

Esta limitación lleva a muchas aplicaciones a adoptar un enfoque de WebView del sistema (por ejemplo, ASWebAuthenticationSession en iOS o Custom Tabs en Android). Los WebViews del sistema aíslan el sitio de terceros (por ejemplo, el proveedor de pagos) en un entorno seguro, similar a un navegador, que permite correctamente las passkeys de origen cruzado, si el propio navegador lo soporta. Sin embargo, recuerda que las limitaciones existentes de Safari para iframes también se aplican a ASWebAuthenticationSession, por lo que si Safari no permite ciertas operaciones de passkey en iframes de terceros, lo mismo ocurrirá en el WebView del sistema. Actualmente no hay una solución "nativa"; la mejor práctica para flujos complejos - como los pagos que involucran a proveedores externos - es abrir un WebView del sistema en lugar de uno incrustado.

Solución: Para los proveedores de pago (y otros terceros que dependen de passkeys entre dominios), planifica cuidadosamente la integración para asegurarte de que el usuario sea sacado de un WebView incrustado y llevado a uno del sistema. Aunque es una experiencia menos fluida que un flujo puramente incrustado, a menudo es la única forma de garantizar que la funcionalidad de passkey funcionará con servicios de terceros.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Para más detalles sobre el manejo de passkeys de terceros dentro de aplicaciones nativas y WebViews, consulta Passkeys para proveedores de pago: SDK de pago con passkeys de terceros.

Aunque los temas discutidos anteriormente se aplican a varios escenarios, son particularmente importantes para los proveedores de pago, donde los flujos multidominio (por ejemplo, el sitio del comerciante y la pasarela de pago) deben incrustar la autenticación de usuarios dentro de iframes de origen cruzado. En estas configuraciones:

• Los usuarios quieren un pago en la página sin fricciones y sin ventanas emergentes de redirección.
• Los proveedores de pago deben manejar el registro o inicio de sesión con passkeys en su propio dominio (por ejemplo, pay.provider.com), incluso si están incrustados en el sitio de un comerciante.
• Las restricciones de Safari y las limitaciones de WebView incrustado a menudo bloquean la creación de passkeys de terceros en iframes.

Para abordar estos desafíos y construir una experiencia segura y fluida similar a la de Apple Pay, los proveedores de pago a menudo adoptan un enfoque híbrido - combinando la integración basada en iframes con una alternativa de redirección para Safari (o navegadores más antiguos). En algunos casos, los flujos de navegador del sistema (por ejemplo, ASWebAuthenticationSession en iOS) se vuelven obligatorios si un WebView incrustado no permite passkeys en absoluto.

Para una inmersión profunda en estos escenarios específicos de pago - incluyendo comparaciones de iframe vs. redirección, consideraciones sobre aplicaciones nativas y mejores prácticas para una alta adopción de passkeys, consulta nuestro artículo dedicado:

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

Get free Whitepaper

En particular:

• Estrategia A: Incrustar un iframe de origen cruzado explica cómo manejar la creación y el inicio de sesión con passkeys en línea, haciendo referencia a la configuración de Permissions-Policy introducida aquí.
• Estrategia B: Enfoque basado en redirección muestra una integración más simple que evita la mayoría de los escollos de origen cruzado, aunque a costa de abandonar el dominio del comerciante.
• WebView del sistema es esencial para las aplicaciones nativas, ya que los WebViews incrustados frecuentemente rompen los flujos de passkeys de terceros.

Esta guía complementaria proporciona estrategias detalladas para asegurar las transacciones, superar las restricciones de origen cruzado de Safari y optimizar el uso de passkeys en contextos de terceros. Al combinar los pasos técnicos de este artículo con esos métodos centrados en los pagos, puedes ofrecer un flujo de pago sin fricciones y resistente al phishing directamente dentro de un iframe, desbloqueando el siguiente nivel de seguridad y UX para los pagos en línea.

La integración de passkeys en iframes mejora significativamente la autenticación de usuarios al optimizar tanto la seguridad como la experiencia del usuario. Esto permite una autenticación fluida sin necesidad de redirecciones o ventanas emergentes, garantizando una UX consistente en varias secciones y sitios.

Implementaciones del mundo real, como la integración de passkeys de Shopify en su componente de inicio de sesión, demuestran los beneficios prácticos y la flexibilidad de este enfoque.