Get your free and exclusive 80-page Banking Passkey Report
webauthn-passkey-qr-code

Códigos QR y Bluetooth para Passkeys WebAuthn: Transporte Híbrido

Descubra cómo las passkeys utilizan códigos QR y Bluetooth para la autenticación multiplataforma, permitiendo inicios de sesión fluidos y seguros en todos los dispositivos sin contraseñas.

Vincent Delitz

Vincent

Created: July 1, 2025

Updated: July 15, 2025


See the original blog version in English here.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Introducción#

Las passkeys están reemplazando cada vez más a las contraseñas como el estándar de facto en la autenticación de usuarios. A diferencia de las contraseñas tradicionales, las passkeys están vinculadas a un ecosistema (p. ej., Llavero de iCloud, Administrador de contraseñas de Google, Windows Hello o un administrador de contraseñas como 1Password o Dashlane); no están diseñadas para ser memorizadas, sino que están construidas para integrarse sin problemas con tus dispositivos, ofreciendo una excelente experiencia de usuario desde el primer momento.

Imagina que estás lejos de tu computadora personal, quizás en una terminal pública o en la laptop de un amigo, y necesitas iniciar sesión en tu cuenta protegida con passkey. Este escenario es bastante común y necesita un método de autenticación seguro pero conveniente, pero con las passkeys muchas personas no saben qué hacer, ya que su passkey no está disponible de inmediato en esta situación. Una de las características de las passkeys para ayudarte en tal situación es la capacidad de emplear tus passkeys en múltiples dispositivos mediante la facilitación de códigos QR y tecnología Bluetooth. Este proceso se conoce formalmente como transporte híbrido en la especificación de WebAuthn (en versiones anteriores de la especificación se le conoce como Bluetooth de baja energía asistido por la nube, caBLE).

StateOfPasskeys Icon

Want to find out how many people use passkeys?

View Adoption Data

El proceso es sencillo: necesitas un dispositivo que tenga tus passkeys almacenadas y que sea capaz de tomar fotos, por lo que lo más probable es que sea un smartphone o una tableta. Este dispositivo puede abrir un túnel hacia el nuevo dispositivo solo para esa instancia de autenticación. Esto no solo mantiene la integridad de tu passkey, sino que también asegura que se pueda dar acceso a tu cuenta en nuevos dispositivos, sin importar dónde te encuentres o qué dispositivo de otra persona quieras usar para iniciar sesión.

Sin embargo, esta característica de autenticación multiplataforma de las passkeys está rodeada de conceptos erróneos y confusión tanto en su utilidad como en su implementación técnica. Esto es algo que noté de nuevo recientemente, cuando visité un meetup local de seguridad informática. A través de este artículo, nuestro objetivo es desentrañar las complejidades y proporcionar recomendaciones para implementar este flujo de autenticación de passkeys multiplataforma (transporte híbrido), asegurando que puedas ofrecer la mejor experiencia de inicio de sesión para tus usuarios.

2. Passkeys: Sincronizadas o solo disponibles en un único dispositivo#

Las passkeys son una forma de autenticación de usuario que reemplaza la contraseña tradicional con un par de claves criptográficas pública-privada más seguro y conveniente. Este par de claves es único para cada usuario y se utiliza para verificar la identidad sin la molestia de recordar contraseñas complejas.

Las ventajas de las passkeys son numerosas en comparación con sus predecesoras, las contraseñas. Reducen significativamente el riesgo de phishing, ya que no pueden ser engañadas para ser compartidas con un sitio web falso. Además, son inmunes a los ataques de fuerza bruta y de diccionario, que son métodos comunes utilizados para descifrar contraseñas. Las passkeys también son más fáciles de usar, eliminando la necesidad de recordar o gestionar una larga lista de contraseñas.

Las passkeys se sincronizan en cuentas en la nube, como las gestionadas por el Administrador de contraseñas de Google o el Llavero de iCloud de Apple (Microsoft con Windows Hello lo hará pronto), o las almacenadas en administradores de contraseñas modernos preparados para passkeys, como 1Password o Dashlane. Sin embargo, es esencial saber que, por defecto, las passkeys están vinculadas al ecosistema y a la respectiva sincronización de la cuenta en la nube. Los sistemas operativos no proporcionan una interfaz para exportar las claves privadas y en la mayoría de los dispositivos, hay un componente de hardware que proporciona medidas de seguridad adicionales para evitar cualquier acceso a las claves privadas, p. ej., el Secure Enclave en dispositivos iOS o el Módulo de plataforma de confianza (TPM) en dispositivos Windows. Solo el proveedor del sistema operativo puede sincronizar las passkeys con otros dispositivos de forma encriptada (protegidas en última instancia por la biometría, el código de acceso o el PIN del usuario). Las claves privadas solo se pueden restaurar y descifrar usando el código de acceso / PIN y se destruirán en caso de que haya demasiados intentos de inicio de sesión fallidos en la cuenta de la nube (p. ej., Apple introduce un límite de tasa para prevenir ataques de fuerza bruta incluso desde una posición privilegiada en el backend de la nube; Google hace lo mismo).

Este diseño inherente significa que si las passkeys no se sincronizan como se describe, acceder a tus passkeys en un nuevo dispositivo puede suponer un desafío. Esta es precisamente la razón por la que existe el método de transporte híbrido para la autenticación multiplataforma de passkeys (transporte híbrido) con código QR y verificación de proximidad por Bluetooth. Proporciona un puente seguro para tus passkeys entre dispositivos sin la necesidad de sincronizarlas a través de una cuenta en la nube / administrador de contraseñas, manteniendo así el principio de que las passkeys pueden permanecer únicamente con el usuario.

Analyzer Icon

Are your users passkey-ready?

Test Passkey-Readiness

3. Configuración técnica de la autenticación de passkeys multiplataforma#

Usar la autenticación de passkeys multiplataforma (transporte híbrido) con transporte híbrido ayuda a superar los problemas entre dispositivos, cuando se accede a una cuenta puramente a través de passkeys. Como no todas las passkeys se sincronizan en cuentas en la nube o administradores de contraseñas, la necesidad de un método fiable para acceder a las passkeys en diferentes dispositivos se vuelve crítica, especialmente al pasar a un nuevo dispositivo o al necesitar acceso en un dispositivo compartido.

3.1 Requisitos de hardware#

Para facilitar la autenticación de passkeys multiplataforma (transporte híbrido), existen los siguientes requisitos de hardware:

  • Soporte de WebAuthn: Los dispositivos deben ser compatibles con WebAuthn. Esto ya se da en el 99% de los dispositivos, según nuestro último análisis de datos de preparación para passkeys.
  • Cámara para escanear códigos QR: Los dispositivos necesitarán una cámara capaz de escanear códigos QR. La mayoría de los smartphones modernos están equipados con cámaras que tienen esta funcionalidad. Además, la cámara necesita capacidades de escaneo de QR integradas (lo que la mayoría de los dispositivos tienen de fábrica). Si tu cámara no lo soporta, un escáner de QR en línea también es una buena opción. De lo contrario, instalar una aplicación de código QR también está bien.
  • Capacidad de Bluetooth: El Bluetooth de baja energía asistido por la nube (caBLE) se utiliza para establecer una conexión segura basada en la proximidad entre dispositivos. Las versiones a buscar son Bluetooth 4.0 o superior, que habilitan la extensión caBLE para WebAuthn.
  • Conexión a Internet: Se necesita una conexión a Internet estable en ambos dispositivos, ya que el intercambio implica abrir un túnel para realizar pasos de verificación que requieren transferencia de datos en tiempo real.
Ben Gould Testimonial

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Más de 10,000 desarrolladores confían en Corbado y hacen de Internet un lugar más seguro con passkeys. ¿Tienes preguntas? Hemos escrito más de 150 artículos de blog sobre passkeys.

Únete a la Comunidad de Passkeys

3.2 Requisitos de software#

Desde el punto de vista del software, existen los siguientes requisitos:

  • Configuración del servidor WebAuthn: Obviamente, necesitas tener un servidor WebAuthn que gestione las claves públicas. Esto también implica habilitar la cuenta del usuario para que se vincule con múltiples autenticadores y configurar el servidor para iniciar la ceremonia de autenticación.
  • API de Web Bluetooth: Para la verificación de proximidad por Bluetooth, necesitarás acceder a la API de Web Bluetooth que activa las capacidades de Bluetooth del dispositivo desde un navegador.
  • Requisitos del sistema operativo: Por favor, consulta la siguiente tabla sobre el soporte de la autenticación entre dispositivos para diferentes sistemas operativos a fecha de marzo de 2025. Autenticador significa que el dispositivo puede servir como el dispositivo que contiene una passkey (en nuestro escenario, el smartphone). Cliente significa el dispositivo que crea el código QR y donde el usuario intenta iniciar sesión (en nuestro escenario, el escritorio):

Fuente: passkeys.dev

4. Passkeys: Código QR#

El proceso para usar la autenticación de passkeys multiplataforma (transporte híbrido) a través de un código QR es el siguiente:

4.1 Iniciar la autenticación de passkeys multiplataforma#

El código QR para la autenticación de passkeys multiplataforma (transporte híbrido) se genera cuando un usuario intenta acceder a un servicio en un dispositivo donde la passkey registrada no está presente, pero el servicio sabe que el usuario debería tener una passkey. Típicamente, se proporciona un botón de "Escanear código QR" o una llamada a la acción similar dentro de la interfaz de autenticación.

4.2 Generar el código QR#

A petición del usuario, el dispositivo inicia la generación de un código QR. Este código QR codifica un identificador de sesión único y sensible al tiempo. Este identificador está vinculado a una sesión que el servidor de autenticación mantiene temporalmente, a la espera de que se complete el proceso de autenticación.

4.3 Escanear el código QR#

El usuario escanea este código QR con un dispositivo donde su passkey está disponible. Las medidas de seguridad incluyen:

  • Uso único: El identificador de sesión dentro del código QR es válido para un solo uso, previniendo ataques de repetición.
  • Cifrado: Todos los datos dentro del código QR están cifrados, asegurando que cualquier comunicación interceptada no pueda ser descifrada por partes no autorizadas.

El código QR escaneado contiene una URI específica con el esquema FIDO, p. ej.: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

4.4 Iniciar el flujo de datos y el proceso de autenticación#

Escanear el código QR hace que el segundo dispositivo del usuario (p. ej., smartphone o tableta) interprete la URI FIDO y se comunique con el servidor de autenticación, enviando una señal de que el usuario está intentando autenticarse a través de un nuevo dispositivo (p. ej., la laptop del amigo). Esta acción solicita al servidor que genere un desafío criptográfico, único para este intento de autenticación.

4.5 Transmitir datos técnicos#

El desafío se envía de vuelta al segundo dispositivo del usuario (p. ej., smartphone o tableta), donde se almacena su passkey. El dispositivo luego crea una firma digital usando la clave privada asociada con la passkey, sin que la clave privada salga nunca del dispositivo (p. ej., smartphone o tableta). El desafío firmado (firma) se envía de vuelta al servidor a través de un túnel seguro y cifrado por Internet, verificando la integridad y el origen del intento de autenticación.

4.6 Validar la firma#

El servidor valida la firma utilizando la clave pública correspondiente ya asociada con la cuenta del usuario. Tras una validación exitosa, el servidor confirma la autenticación, permitiendo al usuario acceder al servicio en el nuevo dispositivo.

Algunos aspectos más importantes de privacidad y seguridad a considerar:

  • Sin intercambio de datos por Bluetooth, solo por Internet: Es importante tener en cuenta que en esta autenticación de passkeys multiplataforma (transporte híbrido) basada en código QR, el Bluetooth no participa en el intercambio de datos. Este proceso depende completamente de una conexión a Internet para la transmisión de datos cifrados entre los dispositivos y el servidor. Sin embargo, el Bluetooth se utiliza para una verificación de proximidad de los dos dispositivos.
  • Las claves privadas no abandonan el dispositivo: Durante todo este proceso, las claves privadas del usuario permanecen seguras en su dispositivo.
  • Sin exposición de datos sensibles: No se transfiere ni se expone información sensible de la passkey o claves privadas durante el proceso de autenticación.
  • Criptografía asimétrica: El mecanismo de desafío-respuesta asegura que lo que se envía son simplemente versiones firmadas y no reutilizables de desafíos que no pueden ser explotados para un acceso no autorizado.

Al adherirse a estos protocolos técnicos y de seguridad, el método de código QR para la autenticación de passkeys multiplataforma (transporte híbrido) mantiene un alto estándar de seguridad mientras proporciona una forma conveniente para que los usuarios autentiquen sus identidades en nuevos dispositivos.

5. Passkeys: Bluetooth (caBLE)#

Además del proceso de escaneo de código QR, también existe la verificación de proximidad a través de Bluetooth (caBLE). Estar seguro de que el cliente y el autenticador están físicamente cerca uno del otro es uno de los principales beneficios del protocolo WebAuthn. A continuación se describen más detalles sobre el funcionamiento interno de este proceso:

5.1 ¿Qué es Bluetooth de baja energía (BLE) en la autenticación?#

Bluetooth de baja energía (BLE) es una tecnología de comunicación inalámbrica diseñada para el intercambio de datos a corta distancia. Juega un papel fundamental en la confirmación de la proximidad física de los dispositivos durante el proceso de autenticación.

5.2 ¿Qué es caBLE (Bluetooth de baja energía asistido por la nube)?#

caBLE es un protocolo que facilita la transferencia segura de información de autenticación entre dispositivos utilizando BLE. Cuando se utiliza caBLE para la autenticación de passkeys multiplataforma (transporte híbrido), el dispositivo que contiene la passkey confirma la proximidad del dispositivo solicitante a través de señales BLE. Una vez verificada la proximidad, el proceso de autenticación continúa, aprovechando BLE para una comunicación local y segura.

5.3 Experiencia de usuario y seguridad con caBLE#

La experiencia del usuario se mejora ya que este método generalmente requiere menos interacción directa del usuario; los dispositivos en proximidad física cercana se detectan automáticamente. En cuanto a la seguridad, caBLE ofrece una ventaja significativa: asegura que el proceso de autenticación solo se lleve a cabo cuando los dos dispositivos están cerca uno del otro, evitando que atacantes remotos inicien el proceso de autenticación.

5.4 Escenario: El dilema del código QR vs. BLE#

Imagina recibir un código QR que redirige a un sitio malicioso. Si la autenticación se realiza a través de este código QR, existe el riesgo de que la sesión o la cookie puedan ser secuestradas. BLE evita este problema al no depender de un escaneo visual, sino de la presencia física de los dispositivos. Esta verificación de proximidad minimiza el riesgo de ataques de intermediario (man-in-the-middle), ya que la verificación de proximidad no ocurre a través de Internet o un medio visual.

5.5 Intercambio de datos y privacidad#

A diferencia de otros métodos, caBLE en realidad no intercambia datos de autenticación como las passkeys. En su lugar, utiliza BLE como un canal de confirmación para establecer que los dispositivos están físicamente cerca. Esta verificación está diseñada para ser parte de un proceso de autenticación multifactor donde la proximidad BLE es uno de los factores, asegurando que incluso si otros factores se ven comprometidos, sin la proximidad física, no se concede el acceso.

Al integrar el protocolo caBLE, los desarrolladores pueden ofrecer un método seguro y fácil de usar para la autenticación de passkeys multiplataforma (transporte híbrido) que mejora la seguridad general del proceso de autenticación. La verificación de proximidad añade una capa adicional de protección que es simple para los usuarios y, sin embargo, protege eficazmente contra ciertos tipos de ciberataques sofisticados.

6. Beneficios#

Existen los siguientes beneficios de este método de autenticación de passkeys multiplataforma (transporte híbrido):

6.1 Camino hacia una buena experiencia de usuario#

La autenticación de passkeys multiplataforma a través de código QR y Bluetooth (transporte híbrido) es una forma de mejorar la UX en escenarios multiplataforma en comparación con no ofrecer ninguna posibilidad en absoluto. Sin embargo, el flujo de usuario es absolutamente nuevo para la mayoría de los usuarios y no esperamos que muchos usuarios no técnicos entiendan lo que está sucediendo la primera vez que se encuentran con este flujo. La única semejanza de introducir el flujo de código QR puede ser con los flujos de inicio de sesión para, por ejemplo, WhatsApp Web o Discord, donde se emplean códigos QR (aunque aquí la funcionalidad es diferente). Por lo tanto, el proceso analizado de autenticación de passkeys multiplataforma a través de código QR / Bluetooth (transporte híbrido) minimiza el esfuerzo del usuario en el escenario multiplataforma, ya que no hay necesidad de introducir manualmente ninguna credencial, pero aun así el flujo general es desconocido para la mayoría de los usuarios.

6.2 Seguridad robusta#

La seguridad de la autenticación de passkeys multiplataforma (transporte híbrido) se refuerza con técnicas criptográficas avanzadas. Cuando se escanea un código QR o se establece una conexión Bluetooth para la autenticación, los desafíos y respuestas criptográficas aseguran que solo el dispositivo previsto pueda completar con éxito el proceso de autenticación.

Las verificaciones de proximidad a través de Bluetooth añaden una capa adicional de seguridad, confirmando que el intento de autenticación está siendo realizado por alguien con acceso físico al dispositivo secundario.

6.3 Integridad de la passkey#

Durante el proceso de autenticación multiplataforma (transporte híbrido), las passkeys nunca se almacenan temporalmente en dispositivos o servidores intermedios, lo que previene el riesgo de que las passkeys sean interceptadas o filtradas durante el proceso de transferencia. La autenticación ocurre en tiempo real, y la passkey permanece vinculada al dispositivo principal del usuario, preservando su integridad.

6.4 Prevención de phishing#

Los métodos de autenticación por código QR y Bluetooth proporcionan inherentemente protección contra el phishing. Es menos probable que los usuarios sean engañados para proporcionar una passkey a un sitio malicioso porque el proceso de autenticación requiere acciones físicas que son específicas de los dispositivos de confianza del usuario.

El proceso de escanear un código QR o conectarse a través de Bluetooth generalmente ocurre en un entorno de confianza, reduciendo la posibilidad de que los usuarios comprometan inadvertidamente sus credenciales.

7. Desventajas#

Existen las siguientes desventajas de este método de autenticación de passkeys multiplataforma (transporte híbrido):

7.1 Familiaridad y adopción del usuario#

Introducir cualquier nueva tecnología puede generar confusión en el usuario, especialmente si los usuarios no son expertos en tecnología. La autenticación de passkeys multiplataforma a través de código QR y Bluetooth (transporte híbrido) es un cambio significativo con respecto a los métodos de autenticación tradicionales, y algunos usuarios podrían encontrar el nuevo proceso difícil de entender, lo que podría llevar a una tasa de adopción más lenta. Sin embargo, esperamos que los usuarios finalmente se acostumbren, por lo que el cambio podría ser más difícil al principio y será más suave y más aceptado con el tiempo.

7.2 Dependencia de las capacidades del dispositivo#

El éxito de la autenticación de passkeys multiplataforma (transporte híbrido) depende en gran medida de que el dispositivo del usuario tenga las capacidades necesarias, como una cámara que pueda escanear códigos QR y funcionalidad Bluetooth. Los usuarios con dispositivos más antiguos que carecen de estas características no podrán aprovechar la autenticación de passkeys multiplataforma (transporte híbrido), creando una brecha digital basada en limitaciones de hardware.

7.3 Comportamiento inconsistente del usuario#

El comportamiento del usuario puede ser impredecible, y la dependencia de que los usuarios realicen acciones específicas como escanear un código QR o habilitar Bluetooth puede introducir errores de usuario. Por ejemplo, el Bluetooth a veces puede ser visto como un desafío de UX debido a problemas de emparejamiento, problemas de descubrimiento y la desconfianza general del usuario hacia las tecnologías inalámbricas para transacciones seguras.

7.4 Adaptación de los desarrolladores#

Los desarrolladores se enfrentan a la tarea de actualizar y mantener constantemente los sistemas para soportar los últimos métodos de autenticación. Integrar la autenticación de passkeys multiplataforma (transporte híbrido) en los sistemas existentes requiere que los desarrolladores se mantengan al día con los nuevos estándares, adopten nuevas API y aseguren la compatibilidad con versiones anteriores, lo que puede ser intensivo en recursos y consumir mucho tiempo.

7.5 Creación de nuevas passkeys#

Para cada nuevo dispositivo o solicitud de inicio de sesión posterior, se necesita crear una nueva passkey si no se utiliza una cuenta en la nube sincronizada como el Llavero de iCloud o un administrador de contraseñas. Esto podría añadir complejidad a la experiencia del usuario y puede crear frustración si los usuarios no están familiarizados con el proceso o si no se hace intuitivo.

7.6 Educar a los usuarios#

Existe una necesidad inherente de educar al usuario al implementar nuevos métodos de seguridad como la autenticación de passkeys multiplataforma (transporte híbrido). Asegurar que los usuarios entiendan cómo usar los códigos QR y el Bluetooth de forma segura requiere una comunicación clara y posiblemente un amplio soporte al cliente.

Aunque la autenticación de passkeys multiplataforma a través de código QR y Bluetooth (transporte híbrido) presenta un avance significativo en la tecnología de autenticación, estas posibles desventajas resaltan la necesidad de un diseño fácil de usar, sistemas de soporte robustos y una transición gradual y bien comunicada de los métodos tradicionales a los innovadores. Como con cualquier cambio tecnológico, equilibrar los beneficios de la innovación con sus desafíos será clave para una implementación exitosa y una amplia aceptación por parte del usuario.

8. Prueba en la vida real: Comportamiento de la passkey de transporte híbrido#

Como descargo de responsabilidad: estamos ignorando las llaves de seguridad de hardware (p. ej., YubiKeys) en la siguiente prueba y solo usamos autenticadores de plataforma que están integrados en los dispositivos (p. ej., Face ID, Touch ID, Windows Hello). En el caso de las llaves de seguridad de hardware (p. ej., YubiKey), los valores para transports serían usb o nfc, por ejemplo.

Estamos utilizando las siguientes combinaciones de dispositivo / navegador y el Passkeys Debugger para probar el comportamiento. Android no se considera ya que Android no puede servir como cliente de autenticación multiplataforma (transporte híbrido) (ver tabla arriba).

Para probar el comportamiento, creamos para cada combinación una nueva passkey con las siguientes propiedades:

  • userName: alex muller (sin influencia en esta prueba)
  • authenticatorAttachment: platform (ya que queremos excluir las llaves de seguridad de hardware como las YubiKeys)
  • residentKey: preferred (sin influencia en esta prueba)
  • userVerification: preferred (sin influencia en esta prueba)
  • attestation: none (sin influencia en esta prueba)
  • hints: empty (ver explicación a continuación)
  • usePRF: no (sin influencia en esta prueba)

Después de la creación exitosa de la passkey, modificamos la entrada de la propiedad allowCredentials del servidor WebAuthn e iniciamos una solicitud de inicio de sesión. Queremos simular una passkey eliminada en el dispositivo donde creamos la passkey, para que el dispositivo / navegador busque otro dispositivo que pueda proporcionar una passkey a través de código QR / Bluetooth. Por lo tanto, cambiamos el ID de la credencial y asignamos el valor CHANGED-ID, para que la coincidencia falle. Además, cambiamos la propiedad transports de una credencial WebAuthn en allowCredentials y asignamos para cada combinación de dispositivo / navegador los siguientes valores:

  1. transports: [internal, hybrid]: Las passkeys se pueden usar desde el autenticador de plataforma (p. ej., Face ID, Touch ID, Windows Hello) o a través de autenticación multiplataforma.
  2. transports: [internal]: Las passkeys se pueden usar desde el autenticador de plataforma (p. ej., Face ID, Touch ID, Windows Hello).
  3. Sin propiedad transports establecida: comportamiento predeterminado que no impone restricciones.

En el sitio de pruebas de WebAuthn, también se proporciona la nueva característica de WebAuthn Nivel 3 para las sugerencias del agente de usuario. Esta característica puede mejorar la experiencia del usuario si la parte de confianza (relying party) tiene ciertas suposiciones sobre cómo se puede completar la solicitud de inicio de sesión de la manera más fácil para el usuario. En esta prueba, no tuvimos en cuenta esta característica ya que aún no está implementada. Por favor, consulta las especificaciones para más detalles.

8.1 Windows 11 23H2 + Chrome 119#

8.1.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.1.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.1.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguna razón, partes del modal aparecen en alemán, que es uno de los idiomas instalados.

8.1.4 allowCredentials vacío#

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR, a través de dispositivos conocidos y a través de llaves de seguridad de hardware.

8.2 Windows 11 23H2 + Edge 119#

8.2.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.2.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.2.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguna razón, partes del modal aparecen en alemán, que es uno de los idiomas instalados.

8.2.4 allowCredentials vacío#

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR, a través de dispositivos conocidos y a través de llaves de seguridad de hardware.

8.3 Windows 11 23H2 + Firefox 119#

Al crear la passkey, recibimos el siguiente error (aun así se creó una passkey):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

8.3.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.3.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.3.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguna razón, partes del modal aparecen en alemán, que es uno de los idiomas instalados.

8.3.4 allowCredentials vacío#

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR, a través de dispositivos conocidos y a través de llaves de seguridad de hardware.

8.4 macOS Ventura + Chrome 119#

8.4.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario). Además, puedes seleccionar directamente uno de los dispositivos conocidos para usar una passkey desde allí.

El modal es bastante diferente a su contraparte en Windows en Chrome 119.

8.4.2 transports: [internal]#

Este es un comportamiento esperado, ya que solo permitimos usar passkeys internas pero no podemos encontrar una credencial interna en el dispositivo (no se nos permite usar passkeys híbridas). La autenticación con passkey falla en este paso y en implementaciones de la vida real, necesitarías proporcionar un método de autenticación de respaldo.

8.4.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante. Además, puedes seleccionar directamente uno de los dispositivos conocidos para usar una passkey desde allí.

El modal es bastante diferente a su contraparte en Windows en Chrome 119.

8.4.4 allowCredentials vacío#

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Touch ID, a través de código QR, a través de dispositivos conocidos y a través de llaves de seguridad de hardware.

8.5 macOS Ventura + Safari 16.6#

8.5.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.5.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.5.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.5.4 allowCredentials vacío#

Como se esperaba, se permiten la mayoría de las formas de autenticación con passkey: a través de Touch ID, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

8.6 iOS 17.1 + Chrome 119#

8.6.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.6.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.6.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.6.4 allowCredentials vacío#

Como se esperaba, se permiten la mayoría de las formas de autenticación con passkey: a través de Face ID, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

8.7 iOS 17.1 + Safari 17.1#

8.7.1 transports: [internal, hybrid]#

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.7.2 transports: [internal]#

De manera bastante confusa, el código QR también se muestra aquí, aunque solo permitamos credenciales internas. No pudimos encontrar una razón válida para este comportamiento.

8.7.3 Sin propiedad transports establecida#

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.7.4 allowCredentials vacío#

Como se esperaba, se permiten la mayoría de las formas de autenticación con passkey: a través de Face ID, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

A continuación, para dispositivos con Windows 10, decidimos ir un nivel más allá y analizar cómo se ve el comportamiento si el Bluetooth está deshabilitado o no está disponible en una máquina con Windows 10 en general. En particular para dispositivos de escritorio más antiguos, este sigue siendo un escenario muy común, ya que estos dispositivos a menudo no tienen un módulo Bluetooth, lo que hace imposible la autenticación multiplataforma a través de código QR y Bluetooth.

8.8 Windows 10 21H2 + Chrome 119#

8.8.1 Bluetooth habilitado#

8.8.1.1 transports: [internal, hybrid]

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario - primera captura de pantalla) o elegir escanear el código QR (segunda captura de pantalla).

8.8.1.2 transports: [internal]

De manera bastante confusa, se te solicita que ingreses tu código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.8.1.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.8.1.4 allowCredentials vacío

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR, a través de dispositivos conocidos y a través de llaves de seguridad de hardware.

8.8.2 Bluetooth deshabilitado#

8.8.2.1 transports: [internal, hybrid]

Este es un mensaje realmente confuso para los usuarios, ya que no se indica explícitamente qué deben hacer y cómo pueden autenticarse. La única opción que tienen es hacer clic en "Cancelar", convirtiendo este escenario en un callejón sin salida.

8.8.2.2 transports: [internal]

Este comportamiento es el mismo que en el caso en que Bluetooth está habilitado. Es muy confuso que se le pida al usuario que ingrese el código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.8.2.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que la única opción que tienes es usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.8.2.4 allowCredentials vacío

La autenticación con passkey solo es posible a través de Windows Hello y llaves de seguridad de hardware.

8.9 Windows 10 21H2 + Edge 119#

8.9.1 Bluetooth habilitado#

8.9.1.1 transports: [internal, hybrid]

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.9.1.2 transports: [internal]

De manera bastante confusa, se te solicita que ingreses tu código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.9.1.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.9.1.4 allowCredentials vacío

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

8.9.2 Bluetooth deshabilitado#

8.9.2.1 transports: [internal, hybrid]

Este es un mensaje realmente confuso para los usuarios, ya que no se indica explícitamente qué deben hacer y cómo pueden autenticarse. La única opción que tienen es hacer clic en "Cancelar", convirtiendo este escenario en un callejón sin salida.

8.9.2.2 transports: [internal]

Este comportamiento es el mismo que en el caso en que Bluetooth está habilitado. Es muy confuso que se le pida al usuario que ingrese el código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.9.2.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que la única opción que tienes es usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.9.2.4 allowCredentials vacío

La autenticación con passkey solo es posible a través de Windows Hello y llaves de seguridad de hardware.

8.10 Windows 10 22H2 + Chrome 119#

8.10.1 Bluetooth habilitado#

8.10.1.1 transports: [internal, hybrid]

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.10.1.2 transports: [internal]

De manera bastante confusa, se te solicita que ingreses tu código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.10.1.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.10.1.4 allowCredentials vacío

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

8.10.2 Bluetooth deshabilitado#

8.10.2.1 transports: [internal, hybrid]

Este es un mensaje realmente confuso para los usuarios, ya que no se indica explícitamente qué deben hacer y cómo pueden autenticarse. La única opción que tienen es hacer clic en "Cancelar", convirtiendo este escenario en un callejón sin salida. Por alguna razón, partes del modal de Seguridad de Windows también se muestran en alemán (un segundo idioma instalado en este dispositivo).

8.10.2.2 transports: [internal]

Este comportamiento es el mismo que en el caso en que Bluetooth está habilitado. Es muy confuso que se le pida al usuario que ingrese el código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.10.2.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que la única opción que tienes es usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.10.2.4 allowCredentials vacío

La autenticación con passkey solo es posible a través de Windows Hello y llaves de seguridad de hardware.

8.11 Windows 10 22H2 + Edge 119#

8.11.1 Bluetooth habilitado#

8.11.1.1 transports: [internal, hybrid]

Como se esperaba, ninguna passkey local coincide, por lo que se sugiere escanear el código QR y usar la passkey en otro dispositivo (ya que el sistema sabe que existe una passkey para este usuario).

8.11.1.2 transports: [internal]

De manera bastante confusa, se te solicita que ingreses tu código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.11.1.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que se sugiere escanear el código QR o usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.11.1.4 allowCredentials vacío

Como se esperaba, se permiten todas las formas de autenticación con passkey: a través de Windows Hello, a través de código QR y a través de llaves de seguridad de hardware. Por alguna razón, los dispositivos conocidos no se muestran.

8.11.2 Bluetooth deshabilitado#

8.11.2.1 transports: [internal, hybrid]

Este es un mensaje realmente confuso para los usuarios, ya que no se indica explícitamente qué deben hacer y cómo pueden autenticarse. La única opción que tienen es hacer clic en "Cancelar", convirtiendo este escenario en un callejón sin salida.

8.11.2.2 transports: [internal]

Este comportamiento es el mismo que en el caso en que Bluetooth está habilitado. Es muy confuso que se le pida al usuario que ingrese el código PIN de Windows Hello (o huella digital / escaneo facial si está configurado en el dispositivo), aunque cambiamos el ID de la credencial (por lo que en realidad no debería encontrar la credencial ya que no está especificada en la propiedad allowCredentials). Sin embargo, después de enviar el código PIN de Windows Hello, se lanza un error: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Desde la perspectiva del usuario, este es un comportamiento bastante confuso pero tiene sentido, ya que podría proporcionar información sobre las passkeys del usuario sin su consentimiento.

8.11.2.3 Sin propiedad transports establecida

Ninguna passkey local coincide, por lo que la única opción que tienes es usar una llave de seguridad de hardware (p. ej., YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.11.2.4 allowCredentials vacío

La autenticación con passkey solo es posible a través de Windows Hello y llaves de seguridad de hardware.

9. Recomendaciones para desarrolladores#

Debugger Icon

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

9.1 Consejos de implementación#

  • Utiliza bibliotecas y frameworks que abstraigan algunas de las complejidades de la API pura de WebAuthn.
  • Considera los escenarios de autenticación multiplataforma desde el principio para asegurar que una amplia base de usuarios pueda beneficiarse de tu implementación de passkeys. Dependiendo de tus elecciones de diseño, también puedes ofrecer métodos de inicio de sesión alternativos en estos escenarios.
  • Desarrolla mecanismos de respaldo para escenarios donde la autenticación multiplataforma de passkeys (transporte híbrido) podría no ser posible debido a limitaciones del dispositivo.
  • La decisión de diseño más importante es decidir si quieres promover la autenticación de passkeys multiplataforma a través de código QR / Bluetooth (transporte híbrido) y convertirla en un método prominente para la autenticación con passkeys o usar sugerencias para no promoverla activamente. En este último caso, siempre se intenta usar inmediatamente las passkeys almacenadas internamente y solo si no se encuentra ninguna passkey interna, se muestra un código QR para la autenticación multiplataforma (transporte híbrido). Esto debe definirse en las opciones de tu servidor WebAuthn en las propiedades excludeCredentials y allowCredentials. En la propiedad excludeCredentials de tu servidor WebAuthn, puedes ver información de transporte sobre las credenciales ya creadas. En la propiedad allowCredentials, puedes especificar el comportamiento en el proceso de inicio de sesión (ver pruebas arriba).
  • Además, no puedes prevenir por completo la autenticación de passkeys multiplataforma (transporte híbrido) (ver las pruebas anteriores con transports: [internal]), por lo que necesitas estar preparado para que tus usuarios encuentren este método y tengan preguntas. La aparición de esta autenticación multiplataforma (transporte híbrido) ocurrirá en particular si los usuarios comienzan a eliminar passkeys localmente.

9.2 Estrategias educativas#

  • Crea guías y tutoriales completos que guíen a los usuarios a través del proceso de autenticación de passkeys multiplataforma (transporte híbrido).
  • Usa tooltips en la aplicación y secciones de ayuda contextual para guiar a los usuarios durante su primera experiencia de autenticación de passkeys multiplataforma (transporte híbrido).
  • Proporciona secciones de preguntas frecuentes y solución de problemas en tu sitio web o dentro de la aplicación.

9.3 Consideraciones sobre el acceso temporal#

  • Implementa sesiones con límite de tiempo para los inicios de sesión con passkey a través de código QR o Bluetooth para asegurar que el acceso sea solo temporal y seguro.
  • Asegúrate de que la autenticación de passkeys multiplataforma (transporte híbrido) no socave ningún protocolo de seguridad existente, manteniendo la integridad de los datos del usuario.
  • Considera las implicaciones de privacidad y asegúrate de que cualquier acceso temporal otorgado a través de la autenticación de passkeys multiplataforma (transporte híbrido) se registre y monitoree de acuerdo con las mejores prácticas de seguridad.

10. Conclusión: Passkeys con código QR / Bluetooth#

La autenticación de passkeys multiplataforma a través de código QR / Bluetooth (transporte híbrido) ofrece un equilibrio entre seguridad y UX. Sin embargo, es un proceso completamente nuevo para la mayoría de los usuarios y podría causar muchas situaciones confusas, por lo que debes pensar cuidadosamente si quieres promoverlo.

Esperamos haber podido arrojar algo de luz sobre el tema de la autenticación de passkeys multiplataforma (transporte híbrido) a través de código QR / Bluetooth, explicar cómo configurar las cosas y cómo se ve el comportamiento en diferentes combinaciones de dispositivo / navegador. Si tienes alguna pregunta, no dudes en contactarnos a través de nuestra comunidad de passkeys o suscribirte a nuestro Substack de passkeys. Hagamos de Internet un lugar más seguro difundiendo las passkeys.

Schedule a call to get your free enterprise passkey assessment.

Talk to a Passkey Expert

Share this article


LinkedInTwitterFacebook

Enjoyed this read?

🤝 Join our Passkeys Community

Share passkeys implementation tips and get support to free the world from passwords.

🚀 Subscribe to Substack

Get the latest news, strategies, and insights about passkeys sent straight to your inbox.

Related Articles

Table of Contents