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
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.
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).
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.
Recent Articles
♟️
Cómo reducir los costos de SMS con passkeys
♟️
Guía: Comprar vs. Desarrollar una Solución de Passkeys
🔑
Por qué la autenticación por SMS cuesta demasiado a las empresas
♟️
Por qué un proveedor de autenticación con passkeys te ahorra más de 100.000 $
♟️
Cómo conseguir una alta adopción de passkeys en los flujos de creación
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.
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.
Para facilitar la autenticación de passkeys multiplataforma (transporte híbrido), existen los siguientes requisitos de hardware:
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 PasskeysDesde el punto de vista del software, existen los siguientes requisitos:
Fuente: passkeys.dev
El proceso para usar la autenticación de passkeys multiplataforma (transporte híbrido) a través de un código QR es el siguiente:
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.
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.
El usuario escanea este código QR con un dispositivo donde su passkey está disponible. Las medidas de seguridad incluyen:
El código QR escaneado contiene una URI específica con el esquema FIDO, p. ej.: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
Existen los siguientes beneficios de este método de autenticación de passkeys multiplataforma (transporte híbrido):
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.
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.
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.
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.
Existen las siguientes desventajas de este método de autenticación de passkeys multiplataforma (transporte híbrido):
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.
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.
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.
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.
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.
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.
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:
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:
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.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.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.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.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.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.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.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.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.
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).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.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.
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