Transportes de WebAuthn: transportes internos e híbridos

Whitepaper empresarial de Passkeys. Guías prácticas, patrones de despliegue y KPIs para programas de passkeys.

Obtener whitepaper

Nota: Según la especificación de WebAuthn, una secuencia de transportes vacía significa que la información del transporte no está disponible o se retiene por privacidad. Los navegadores suelen tratarla como si todos los transportes fueran posibles.

Al implementar claves de acceso en varias plataformas, los desarrolladores se enfrentan a una decisión importante:

• ¿Cómo debe manejar los transportes de WebAuthn, en particular los transportes internos e híbridos, para garantizar experiencias óptimas de autenticación entre dispositivos?

La respuesta radica en comprender los transportes de WebAuthn, un detalle técnico que determina cómo se comunican los autenticadores con los usuarios de confianza. Aunque los transportes parecen sencillos en teoría, su implementación varía significativamente en navegadores web, aplicaciones nativas de iOS y aplicaciones nativas de Android, particularmente para el manejo de transportes internos e híbridos.

Este artículo examina cómo funcionan los transportes de WebAuthn en diferentes plataformas y presenta dos enfoques distintos para manejar los transportes internos e híbridos, cada uno con sus propias ventajas y desventajas.

Este artículo cubre:

1. Transportes de WebAuthn: internos, híbridos y autenticadores de plataforma en la web, iOS y Android
2. Dos enfoques: manejo de transportes internos e híbridos conforme a la especificación frente a optimizado
3. Mejores prácticas y recomendaciones de implementación de autenticación entre dispositivos

Los transportes de WebAuthn definen los métodos de comunicación entre los autenticadores y los dispositivos cliente. La especificación de WebAuthn Nivel 3 define seis tipos de transporte:

usb: Utilizado por llaves de seguridad de hardware que se conectan a través de puertos USB, como YubiKeys u otros tokens de seguridad FIDO2.

nfc: Permite la comunicación con autenticadores mediante Near Field Communication (comunicación de campo cercano), lo que permite a los usuarios acercar sus llaves de seguridad o dispositivos habilitados para NFC.

ble: Facilita la autenticación a través de Bluetooth Low Energy (Bluetooth de baja energía), lo que permite la comunicación inalámbrica con autenticadores externos.

smart-card: Utilizado para lectores de tarjetas inteligentes, permitiendo la autenticación a través de tarjetas inteligentes.

hybrid: Permite la autenticación entre dispositivos, generalmente cuando un usuario escanea un código QR para autenticarse en varios dispositivos, como usar un teléfono para autenticarse en un navegador de escritorio, o viceversa. Este transporte puede activar avisos de códigos QR en dispositivos de escritorio y móviles, lo que puede no ser siempre deseable según el contexto. Nota: se agregó hybrid en WebAuthn Nivel 3.

internal: El autenticador está integrado en el propio dispositivo, como el Llavero de iCloud (verificado mediante Face ID o Touch ID) en iPhones, Windows Hello en PC o Google Password Manager en dispositivos Android. Estos son autenticadores de plataforma.

Cuando se crea una clave de acceso, el autenticador señala qué transportes admite. Esta información se envía al usuario de confianza (su backend), que debe conservarla junto con la credencial. Durante la autenticación, el usuario de confianza devuelve estos transportes al cliente en la lista allowCredentials, lo que ayuda al navegador o a la plataforma a determinar qué métodos de autenticación ofrecer al usuario.

El manejo del transporte difiere significativamente de una plataforma a otra, lo que crea los desafíos de compatibilidad a los que se enfrentan los desarrolladores.

Los navegadores reciben información de transporte de los autenticadores y la respetan durante los flujos de autenticación. Cuando crea una clave de acceso en Chrome, Safari o Edge, el administrador de credenciales del navegador proporciona datos de transporte que varían en función del autenticador subyacente:

Autenticadores de plataforma: Windows Hello proporciona únicamente ["internal"], lo que refleja su naturaleza vinculada al dispositivo. Sin embargo, cuando Chrome usa Google Password Manager como autenticador, proporciona ["internal", "hybrid"] porque Google Password Manager admite la autenticación entre dispositivos a través de teléfonos Android.

Llaves de seguridad de hardware: Proporcionan transportes específicos como ["usb", "nfc"] en función de sus capacidades reales.

Administradores de credenciales sincronizados en la nube: El Llavero de iCloud en Safari y Google Password Manager en Chrome suelen proporcionar ["internal", "hybrid"] para admitir flujos de autenticación tanto locales como entre dispositivos.

Esta información fluye de manera confiable en contextos web, aunque los transportes específicos dependen del autenticador que seleccione el navegador para el almacenamiento de credenciales.

Documentación: Especificación de WebAuthn del W3C

La API de Administrador de credenciales de Android se comporta de manera similar a los navegadores web. Al crear claves de acceso en aplicaciones nativas de Android, el Administrador de credenciales proporciona información de transporte que refleja el comportamiento web: los autenticadores de plataforma informan de sus capacidades con precisión y el sistema maneja los datos de transporte de manera consistente. Los desarrolladores de Android pueden confiar en esta información sin un manejo especial.

Documentación: Administrador de credenciales de Android

iOS presenta una situación más compleja. El marco de trabajo AuthenticationServices de Apple maneja los transportes de manera diferente en función del tipo de autenticador:

Autenticadores de plataforma (Llavero de iCloud, verificado a través de Face ID o Touch ID): A menudo devuelven matrices de transporte vacías durante la creación de la clave de acceso. Esto indica que la información del transporte no está disponible o se retiene por privacidad; de acuerdo con la especificación de WebAuthn, los agentes de usuario pueden devolver secuencias vacías cuando se desconoce la información del transporte o para preservar la privacidad. Los usuarios de confianza deben tratar los transportes como sugerencias en lugar de garantías.

Llaves de seguridad: Proporcionan información de transporte (por ejemplo, ["usb"], ["nfc"]) cuando se usan con dispositivos iOS, siguiendo el patrón esperado.

Documentación: AuthenticationServices de Apple

Los datos de producción del mundo real de aplicaciones web y nativas revelan los siguientes patrones de transporte, ordenados por frecuencia. Tenga en cuenta que estas distribuciones están influenciadas por detalles de implementación y datos demográficos de los clientes (uso en dispositivos móviles frente a computadoras de escritorio, disponibilidad de aplicaciones nativas), pero proporcionan información valiosa sobre el uso típico del transporte:

Conclusiones clave:

Dominan los autenticadores de plataforma: La gran mayoría de las claves de acceso utilizan el transporte internal, a menudo combinado con hybrid para compatibilidad con la autenticación entre dispositivos. Esto refleja el enfoque del consumidor en los autenticadores de plataforma (Llavero de iCloud, Google Password Manager).

Las matrices vacías son comunes: Las aplicaciones nativas de iOS con frecuencia devuelven matrices de transporte vacías para los autenticadores de plataforma, lo que representa una parte significativa de las credenciales de producción. Como se analizó en la sección 2.2.3, estas indican que la información del transporte no está disponible en lugar de una compatibilidad completa con el transporte.

Las llaves de seguridad son poco comunes: Las llaves de seguridad de hardware (usb, nfc) representan una pequeña fracción de las claves de acceso de producción, lo que indica su uso principal en escenarios empresariales o de alta seguridad en lugar de en aplicaciones de consumo.

Existen variaciones en el orden: El orden de los transportes en las matrices (["internal", "hybrid"] frente a ["hybrid", "internal"]) varía según la plataforma y la implementación del autenticador, pero no tiene ninguna diferencia funcional: ambos indican compatibilidad con los mismos métodos de transporte.

Terminología heredada: El identificador de transporte cable aparece ocasionalmente en implementaciones más antiguas y es sinónimo de hybrid (caBLE = Bluetooth de baja energía asistido por la nube, el nombre original del transporte híbrido).

Esta distribución refuerza la importancia de manejar correctamente los transportes internal e hybrid, ya que representan la gran mayoría de las implementaciones de claves de acceso del mundo real.

La disponibilidad de transportes muestra lo que informan los autenticadores, no si el flujo resultante se completa. El análisis de finalización de la autenticación entre dispositivos del Corbado Passkey Benchmark 2026 mide la finalización del transporte hybrid del Q1 de 2026 en un 60-78 % en la web de Windows y un 66-86 % en la web de macOS en general, dividiéndose en un 79-98 % (Win) / 83-98 % (macOS) para recordatorios en el mismo dispositivo frente a un 52-67 % (Win) / 59-76 % (macOS) para flujos de identificador primero. Trate a hybrid como el transporte de mayor costo en la lógica de enrutamiento y prefiera los flujos que mantengan al usuario en el dispositivo que contiene la credencial.

El mismo autenticador suele informar sobre diferentes patrones de transporte en función de la plataforma, la versión y el contexto de implementación. Esta variación es normal y previsible:

El Llavero de iCloud exhibe tres patrones:

• ["internal", "hybrid"] - El más común, generalmente desde navegadores web
• [] (matriz vacía) - Muy común, desde aplicaciones nativas de iOS
• ["hybrid", "internal"] - Menos común, variación de orden
• ["internal"] o ["hybrid"] solos - Casos atípicos poco comunes

Google Password Manager muestra la mayor variación:

• ["hybrid", "internal"] - Patrón más común
• ["internal", "hybrid"] - Ordenación alternativa común
• ["internal", "cable"] - Implementaciones heredadas (cable = término antiguo para el híbrido)
• [] (matriz vacía) - Desde determinados contextos nativos
• Transportes únicos rara vez

Windows Hello es el más consistente:

• ["internal"] - Patrón dominante (vinculado al dispositivo por diseño)

Los administradores de contraseñas como 1Password, Bitwarden, Dashlane y LastPass muestran patrones de variación similares:

• Tanto ordenaciones ["internal", "hybrid"] como ["hybrid", "internal"]
• Matrices vacías [] de contextos de aplicaciones nativas
• Ocasionalmente solo ["internal"]

Samsung Pass (ecosistema Android) utiliza principalmente:

• ["hybrid", "internal"] e ["internal", "hybrid"] - Ambas ordenaciones comunes

Diferencias de plataforma: El mismo autenticador se comporta de manera diferente en la web frente a lo nativo, iOS frente a Android o Windows frente a macOS.

Evolución de la versión: Los informes de transporte han evolucionado con el tiempo. Las versiones anteriores pueden utilizar cable en lugar de hybrid, o informar de diferentes combinaciones.

Opciones de implementación: Algunos autenticadores dan prioridad a internal en primer lugar y otros a hybrid. El orden no tiene impacto funcional, pero varía según la implementación.

Sensibilidad al contexto: Las aplicaciones nativas, especialmente en iOS, suelen recibir matrices vacías incluso de autenticadores que informan transportes completos en contextos web.

Conclusión clave: No asuma que las matrices de transporte serán consistentes para un autenticador determinado. Diseñe su implementación para manejar todas las variaciones sin problemas, centrándose en la presencia de transportes específicos en lugar de en la coincidencia exacta de la matriz.

Los desarrolladores se enfrentan a una opción: seguir la especificación de manera estricta u optimizar los transportes internos e híbridos para la experiencia del usuario. Cada enfoque tiene sus méritos e inconvenientes.

Este enfoque se alinea con la especificación de WebAuthn: utilice los transportes exactamente como los proporciona el autenticador durante el registro de credenciales y envíelos sin cambios durante la autenticación.

Implementación: Cuando se crea una clave de acceso, persista la matriz transports a partir de la respuesta del autenticador. Durante la autenticación, incluya estos transportes exactos en la lista allowCredentials:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Ventajas:

• Cumplimiento de la especificación: Sigue los estándares de WebAuthn con precisión, lo que garantiza la compatibilidad con futuras actualizaciones de la plataforma
• Fiabilidad de la llave de seguridad: Funciona perfectamente para llaves de seguridad de hardware (YubiKeys, etc.) que siempre proporcionan información de transporte precisa
• Evita opciones no válidas: Evita ofrecer métodos de autenticación que realmente no son compatibles (por ejemplo, no activará códigos QR para credenciales de Windows Hello)

Desventajas:

• Comportamiento de la matriz vacía de iOS: Los autenticadores de plataforma en iOS devuelven transportes vacíos, lo que indica que la información del transporte no está disponible; las plataformas pueden interpretar esto de manera diferente a la hora de determinar qué opciones de autenticación mostrar
• Puede mostrar opciones no deseadas: Podría presentar opciones de llaves de seguridad (USB, NFC) en aplicaciones de consumo donde no se esperan
• Experiencia de usuario inconsistente: Las diferentes plataformas ofrecen diferentes opciones de autenticación para la misma cuenta

Ideal para: Aplicaciones que priorizan el cumplimiento de los estándares, entornos empresariales con diversos tipos de autenticador.

Este enfoque da prioridad a la experiencia del usuario modificando selectivamente los transportes internos e híbridos en función de los objetivos de optimización específicos. En lugar de una regla general, tenga en cuenta los siguientes escenarios de optimización comunes:

Problema: Los autenticadores de plataforma de iOS devuelven matrices de transporte vacías. Si se dejan vacíos o los completan los backends, los usuarios pueden ver avisos de llaves de seguridad (USB, NFC) junto a las opciones de la plataforma, lo que genera confusión en las aplicaciones de consumo.

Solución: Establezca explícitamente los transportes en ["hybrid", "internal"] para los autenticadores de la plataforma iOS. Esto garantiza que solo se ofrezcan flujos cruzados entre dispositivos y de autenticación de plataforma, ocultando las opciones de llave de seguridad.

// Cuando se persisten las credenciales del autenticador de la plataforma iOS
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Resultado: Interfaz de autenticación limpia sin avisos de llaves de seguridad para claves de acceso creadas en iOS.

Problema: Al autenticarse en dispositivos móviles, mostrar códigos QR para la autenticación entre dispositivos crea una experiencia de usuario deficiente; los usuarios ya se encuentran en un dispositivo móvil con sus claves de acceso disponibles.

Solución: Elimine el transporte hybrid cuando el usuario se esté autenticando desde un dispositivo móvil, dejando solo ["internal"].

// Al construir allowCredentials para la autenticación
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Resultado: Los usuarios de dispositivos móviles solo ven opciones de autenticación directa sin avisos innecesarios de códigos QR.

⚠️ Precaución: La manipulación del transporte no siempre produce resultados consistentes en todas las plataformas. Las pruebas exhaustivas muestran que las combinaciones de navegador y sistema operativo manejan los transportes de manera diferente:

• Algunas plataformas muestran códigos QR incluso cuando se excluye hybrid de los transportes
• Otras ocultan los códigos QR incluso cuando se incluye hybrid
• El comportamiento varía significativamente entre Chrome, Edge, Safari y Firefox en Windows, macOS e iOS

Riesgo de callejones sin salida: Un filtrado de transporte excesivamente restrictivo puede crear callejones sin salida en la autenticación donde los usuarios no pueden iniciar sesión en absoluto. Por ejemplo, al eliminar hybrid se podrían evitar escenarios legítimos de autenticación entre dispositivos en los que un usuario necesita autenticarse desde un dispositivo prestado. Proporcione siempre métodos de autenticación de respaldo y pruébelos exhaustivamente en sus plataformas de destino antes de implementar optimizaciones de transporte.

Estas son sugerencias de optimización: WebAuthn proporciona otros mecanismos para optimizar la experiencia del usuario de autenticación más allá de la manipulación del transporte, como sugerencias.

El comportamiento del transporte es impredecible: La autenticación entre dispositivos (CDA) a través del transporte hybrid exhibe un comportamiento inconsistente en las combinaciones de navegador y sistema operativo. Las pruebas en el mundo real demuestran que los valores de transporte no garantizan un comportamiento específico de la interfaz de usuario; las plataformas interpretan y manejan los transportes de manera diferente, lo que lleva a resultados inesperados.

Complejidad específica de la plataforma: Al controlar de forma explícita los transportes, debe tener en cuenta las diferencias de plataforma:

• iOS: Envía matrices vacías para autenticadores de plataforma; requiere relleno
• Windows Hello: Debe permanecer únicamente como ["internal"]; añadir hybrid activa códigos QR no deseados
• Web y Android: Generalmente proporcionan información de transporte precisa
• Variaciones de CDA: Los avisos de código QR pueden aparecer o desaparecer sin importar la presencia de hybrid en la matriz de transportes

Se requiere comprensión de extremo a extremo: Controlar de forma explícita los transportes significa asumir la responsabilidad de todo el flujo. Debe comprender cómo se comporta cada combinación de transporte en todas las plataformas de destino y realizar pruebas exhaustivas. La manipulación del transporte puede crear callejones sin salida de autenticación en los que no existe una ruta de autenticación válida para los usuarios.

Ventajas:

• Experiencia de usuario personalizada: Controle exactamente qué opciones de autenticación ven los usuarios en contextos específicos
• Resuelve el problema de la matriz vacía de iOS: Define explícitamente los transportes cuando iOS no proporciona ninguno
• Optimización adaptada al contexto: Adapte la interfaz de autenticación en función del tipo de dispositivo

Desventajas:

• Comportamiento impredecible: La manipulación del transporte no garantiza un comportamiento consistente de la interfaz de usuario; las pruebas exhaustivas muestran que las plataformas interpretan los transportes de manera diferente, mostrando u ocultando opciones en ocasiones sin importar los valores de transporte
• Riesgo de callejones sin salida de autenticación: Un filtrado de transporte excesivamente restrictivo puede evitar que los usuarios se autentiquen por completo, especialmente en escenarios entre dispositivos
• Se desvía de la especificación: Se aleja de las recomendaciones de las especificaciones, lo que puede causar problemas con futuros cambios en la plataforma
• Carga de mantenimiento: Requiere actualizaciones y lógica específicas de la plataforma en curso a medida que evolucionan las plataformas
• Complejidad: Debe manejar de forma manual las matrices vacías de iOS, las restricciones de Windows Hello y otras peculiaridades de la plataforma
• Sobrecarga de pruebas: Cada regla de optimización necesita verificación en todas las combinaciones de plataforma

Ideal para: Aplicaciones de consumo con requisitos de experiencia de usuario específicos, equipos con recursos para mantener lógica específica de la plataforma, escenarios que priorizan flujos de autenticación optimizados sobre el cumplimiento estricto de especificaciones.

El manejo del transporte de WebAuthn no existe de forma aislada; es una parte integral de su estrategia general de implementación de claves de acceso. Surgen dos enfoques comunes en las implementaciones de producción, cada uno con diferentes implicaciones para el uso del transporte interno e híbrido.

Este enfoque prioriza la flexibilidad y el cumplimiento de los estándares, lo que permite a los usuarios autenticarse con cualquier autenticador compatible.

Características de implementación:

• Interfaz de usuario de autenticación: El botón de la clave de acceso aparece junto con las opciones de inicio de sesión existentes (nombre de usuario / contraseña)
• allowCredentials: Se establece en la matriz vacía [], lo que permite que coincida cualquier credencial
• Tipos de autenticadores: Llaves de seguridad, autenticación entre dispositivos (códigos QR), autenticadores de plataforma todos admitidos
• Requisitos de la aplicación nativa: Debe ser compatible con todos los métodos de autenticación, incluidas las llaves de seguridad
• preferImmediatelyAvailableCredentials: No se puede utilizar, ya que excluye por definición las llaves de seguridad y los inicios de sesión con código QR
• Manejo del transporte: Debe dar cabida a todos los tipos de transporte, incluidos los transportes de llave de seguridad (usb, nfc, ble)

Implicaciones de transporte:

Con allowCredentials vacíos, los transportes se vuelven menos críticos durante la autenticación: la plataforma muestra todas las opciones disponibles. Sin embargo, esto significa que los usuarios pueden ver mensajes de llave de seguridad, códigos QR y opciones de plataforma simultáneamente, lo que puede crear una parálisis de decisión en las aplicaciones de consumo.

Ideal para: Entornos empresariales, aplicaciones con bases de usuarios diversas que requieren compatibilidad con llaves de seguridad, escenarios que priorizan la máxima flexibilidad de autenticación.

Este enfoque optimiza la experiencia de usuario del consumidor al restringir la creación de claves de acceso a autenticadores de plataforma y usar flujos de identificador primero.

Características de implementación:

• Creación de claves de acceso: Los avisos iniciados por el usuario (avisos posteriores al inicio de sesión, flujos de creación automática) utilizan authenticatorAttachment: "platform" para centrarse en los autenticadores disponibles de inmediato
• Compatibilidad con llaves de seguridad: Disponible a través de la configuración de cuenta web sin la restricción authenticatorAttachment, lo que permite a los usuarios avanzados seleccionar cualquier autenticador, incluidas las llaves de seguridad
• Flujo de autenticación: Identificador primero: los usuarios ingresan el correo electrónico / nombre de usuario antes de la autenticación
• allowCredentials: Se completa con las credenciales específicas del usuario (no vacías) una vez que se conoce el identificador
• Tipos de autenticador: Autenticadores de plataforma y autenticación entre dispositivos priorizados; se admiten las llaves de seguridad, pero no se promocionan en los flujos principales
• Optimización de aplicaciones nativas: Utiliza preferImmediatelyAvailableCredentials para una autenticación silenciosa e instantánea sin avisos para llaves de seguridad o códigos QR
• Autenticación entre dispositivos: Disponible en la web; excluido intencionalmente en las aplicaciones nativas al usar preferImmediatelyAvailableCredentials (los usuarios generalmente se autentican en el dispositivo donde residen sus claves de acceso)
• Manejo del transporte: Enfoque principal en transportes internal e hybrid

Implicaciones de transporte:

Dado que allowCredentials contiene credenciales específicas con sus transportes, el manejo del transporte se vuelve crucial para optimizar las experiencias de autenticación.

Realidad de las llaves de seguridad: Las llaves de seguridad representan una fracción extremadamente pequeña del uso de claves de acceso en implementaciones de consumo a gran escala, principalmente usuarios avanzados o usuarios con requisitos de seguridad específicos. El enfoque adaptado al consumidor reconoce esta realidad al admitir llaves de seguridad sin optimizar los flujos principales a su alrededor.

Estrategia de creación de dos niveles: Las implementaciones pueden equilibrar la compatibilidad de las llaves de seguridad con una experiencia de usuario de consumo optimizada a través de rutas de creación duales:

• Recordatorios y avisos al usuario: Los avisos posteriores al inicio de sesión y los flujos de creación automática utilizan authenticatorAttachment: "platform", lo que guía a los usuarios hacia claves de acceso disponibles de inmediato con altas tasas de éxito
• Configuración de la cuenta web: Ofrece la creación sin authenticatorAttachment, lo que permite a los usuarios avanzados seleccionar llaves de seguridad, administradores de contraseñas de terceros o cualquier autenticador disponible

Este patrón aparece en implementaciones importantes: las llaves de seguridad son compatibles y funcionales a través de la configuración, pero los avisos orientados al usuario se optimizan para el caso de uso dominante: autenticadores de plataforma que proporcionan una autenticación silenciosa e instantánea.

Ideal para: Aplicaciones de consumo, aplicaciones móviles nativas, escenarios que priorizan la experiencia del usuario optimizada sobre la flexibilidad del autenticador, plataformas donde ya existen flujos de identificador primero.

Para las plataformas que ya filtran la existencia de cuentas o usan flujos de identificador primero (el usuario ingresa el correo electrónico antes de ver las opciones de inicio de sesión), el enfoque adaptado al consumidor se alinea de manera natural. Una vez que el usuario ha proporcionado su identificador:

1. El backend consulta las claves de acceso existentes
2. Devuelve allowCredentials con credenciales específicas y sus transportes
3. La plataforma puede optimizar la interfaz de autenticación en función de los transportes
4. No hay riesgo adicional de enumeración de cuentas (el identificador ya se proporcionó)

En estos escenarios, los transportes pueden convertirse en una herramienta de optimización en lugar de en una preocupación de seguridad. Puede adaptar las opciones de autenticación según el contexto del dispositivo (móvil frente a computadora de escritorio) y las capacidades de credenciales.

Recomendación: Para las plataformas que ya usan flujos de identificador primero o donde la enumeración de cuentas no es una preocupación, el enfoque adaptado al consumidor con un manejo explícito del transporte proporciona una experiencia de usuario superior, especialmente en aplicaciones móviles nativas donde preferImmediatelyAvailableCredentials permite una autenticación biométrica fluida.

Sin importar qué enfoque elija para manejar los transportes internos e híbridos, siga estas prácticas para minimizar los problemas:

Conserve los transportes durante el registro: Guarde siempre la matriz transports desde la respuesta del autenticador junto con la clave pública y la identificación de la credencial. Estos datos son esenciales para los flujos de autenticación.

Gestione las matrices vacías con cuidado: Al recibir una matriz de transporte vacía de los autenticadores de la plataforma iOS:

• Cumplimiento de la especificación: Déjela vacía u omita la propiedad de transporte: indica que la información del transporte no está disponible; las plataformas determinarán las opciones disponibles
• Enfoque de optimización: Rellénelo con ["internal", "hybrid"] para controlar qué opciones de autenticación se muestran

Estrategias de transporte web frente a estrategias nativas: Diferencie el manejo del transporte en función del contexto:

• Autenticación web: Incluya todos los transportes, lo que permite una mayor compatibilidad de los autenticadores, incluidas las llaves de seguridad a través de USB/NFC
• Autenticación de aplicaciones nativas: Utilice preferImmediatelyAvailableCredentials para una autenticación silenciosa; los transportes se envían tal y como se almacenan
• Páginas de configuración/administración: Compatibilidad con todos los tipos de autenticador para usuarios avanzados

Controlar la autenticación con llave de seguridad: Cuando los usuarios tienen llaves de seguridad registradas:

• Web: Detecte los transportes de llaves de seguridad en las credenciales almacenadas y asegúrese de que los flujos de autenticación puedan adaptarse a ellas
• Aplicaciones nativas: Considere la posibilidad de proporcionar métodos de autenticación de respaldo o de dirigir a los usuarios a la web para la autenticación de la llave de seguridad
• Enfoque híbrido: Las aplicaciones nativas se optimizan para los autenticadores de plataforma, mientras que la web admite la flexibilidad total de los autenticadores

Pruebe en todas las plataformas de destino: Cree una matriz de pruebas que cubra todas las combinaciones:

• Registro: Web, iOS nativo, Android nativo
• Autenticación: Web, iOS nativo, Android nativo
• Verifique que la autenticación silenciosa funciona con preferImmediatelyAvailableCredentials
• Confirme que las llaves de seguridad funcionan en los flujos de configuración sin authenticatorAttachment
• Valide que los códigos QR solo aparecen en los contextos apropiados

Comprenda la semántica del transporte: Reconozca las diferencias entre los valores de transporte vacíos y los que faltan:

• Matriz de transportes vacía []: Indica que la información del transporte no está disponible o se retiene por motivos de privacidad. Los agentes de usuario pueden proporcionar secuencias vacías cuando no pueden o deciden no informar las capacidades del transporte. Esto no equivale a "todos los transportes admitidos"; trátelos como sugerencias en los casos en que la información no esté disponible.
• Propiedad de transportes faltante: Cuando se omiten transportes de los descriptores de credenciales, los agentes de usuario determinan los métodos de autenticación disponibles basándose en otros factores. El contexto es importante: en las respuestas de registro frente a las opciones de solicitud de autenticación, las implicaciones difieren.
• Sugerencias de transporte: Según la especificación, los transportes deben tratarse como sugerencias para ayudar a los agentes de usuario a optimizar la interfaz de usuario de autenticación, no como garantías autoritarias de sus capacidades.

Supervisar los cambios en la plataforma: Las implementaciones de WebAuthn evolucionan. Apple, Google y Microsoft actualizan periódicamente los comportamientos de sus autenticadores. Manténgase informado sobre los cambios que puedan afectar al manejo del transporte.

Los transportes de WebAuthn, en especial los transportes internos e híbridos, son detalles técnicos con un impacto práctico significativo en la autenticación entre dispositivos. Su estrategia de manejo de transporte debe alinearse con su enfoque de implementación de claves de acceso más amplio y las plataformas de destino.

Las decisiones de transporte forman parte de una estrategia más amplia: La forma en que maneje los transportes depende de si está trabajando para obtener la máxima flexibilidad (allowCredentials vacíos) o la experiencia de usuario del consumidor (identificador primero con credenciales específicas). Esto último hace que los transportes sean críticos para la optimización.

Las diferencias de la plataforma requieren manejo: Web y Android proporcionan información de transporte confiable, mientras que los autenticadores de la plataforma iOS devuelven matrices vacías. Windows Hello envía solo ["internal"]. Comprender estas diferencias es esencial para las implementaciones de producción.

Dos enfoques de transporte válidos: El enfoque compatible con las especificaciones (confiar en los transportes del autenticador) funciona bien para escenarios empresariales y de máxima flexibilidad. El control explícito (optimizar transportes) se adapta a las aplicaciones de consumo con flujos de identificador primero y a las aplicaciones móviles nativas.

El identificador primero permite la optimización del transporte: Cuando los usuarios proporcionan su identificador en primer lugar, el manejo del transporte se convierte en una potente herramienta de UX. Puede evitar códigos QR no deseados en dispositivos móviles, ocultar las opciones de llaves de seguridad y optimizar la autenticación, sin preocupaciones adicionales por la enumeración de cuentas.

Para empresas / Máxima flexibilidad:

• Utilice un allowCredentials vacío para admitir todos los tipos de autenticadores
• Confíe en los transportes proporcionados por el autenticador
• Acepte que los usuarios ven más opciones de autenticación
• Implementación más simple, compatibilidad más amplia

Para aplicaciones de consumo / Aplicaciones nativas:

• Implementar un flujo de autenticación de identificador primero
• Recordatorios a los usuarios (posteriores al inicio de sesión, avisos automáticos): Utilice authenticatorAttachment: "platform" para una autenticación inmediata exitosa
• Configuración de la cuenta web: Permita la creación sin authenticatorAttachment para los usuarios avanzados que necesiten llaves de seguridad
• Utilice allowCredentials con credenciales específicas y transportes optimizados
• Aplicaciones nativas: Habilite preferImmediatelyAvailableCredentials para la autenticación silenciosa
• Rellene las matrices vacías de iOS con ["hybrid", "internal"]
• Autenticación web: Admita todos los transportes, incluidas las llaves de seguridad
• Filtre hybrid en dispositivos móviles para evitar códigos QR donde corresponda
• Experiencia de usuario superior con opciones de autenticación optimizadas mientras se mantiene la compatibilidad

Para plataformas con flujos de identificador primero ya:

• La enumeración de cuentas ya no es un problema
• El enfoque adaptado al consumidor se alinea de manera natural con la experiencia de usuario existente
• La optimización del transporte proporciona beneficios inmediatos de experiencia de usuario
• Enfoque recomendado para la mayoría de las aplicaciones de consumo

Comience cumpliendo con las especificaciones, y después optimice basándose en su estrategia:

1. Conserve los transportes exactamente como se recibieron durante el registro
2. Decida su estrategia general (máxima flexibilidad frente a adaptada al consumidor)
3. Si está adaptado al consumidor: implemente un flujo de identificador primero y optimice los transportes
4. Gestione las matrices vacías de iOS de forma adecuada para la estrategia elegida
5. Pruebe exhaustivamente en las plataformas Web, iOS Nativo y Android Nativo

El entorno de WebAuthn continúa evolucionando. Los proveedores de plataformas actualizan regularmente sus implementaciones, y las especificaciones como WebAuthn Nivel 3 introducen nuevas capacidades. La creación de sistemas flexibles que alineen el manejo del transporte con su estrategia de autenticación más amplia garantiza que su implementación de claves de acceso siga siendo sólida y proporcione experiencias de usuario excelentes a medida que el ecosistema madura.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

AuthenticationServices de iOS retiene la información de transporte para autenticadores de plataforma como Llavero de iCloud, devolviendo matrices vacías según las disposiciones de privacidad de la especificación de WebAuthn. Las llaves de seguridad en iOS sí proporcionan datos de transporte, como ["usb"] o ["nfc"]. Los usuarios de confianza deben tratar todos los transportes como sugerencias en lugar de garantías autoritativas de capacidad.

cable es una terminología heredada sinónima de hybrid, que significa caBLE (Bluetooth de baja energía asistido por la nube). Ambos describen la autenticación entre dispositivos, como escanear un código QR para autenticar una sesión de escritorio mediante un teléfono. hybrid es el término actual introducido en WebAuthn Nivel 3 y debe usarse en implementaciones nuevas.

Para las aplicaciones de consumo que utilizan flujos de identificador primero, establezca explícitamente los transportes en ["hybrid", "internal"] para los autenticadores de la plataforma iOS que devolvieron matrices vacías durante el registro. Esto evita que los avisos de las llaves de seguridad USB y NFC aparezcan en la interfaz de autenticación. La alternativa que cumple con las especificaciones es dejar las matrices vacías u omitir la propiedad de transportes por completo.

Al eliminar el transporte hybrid en los dispositivos móviles, se evitan los avisos de códigos QR cuando los usuarios ya se encuentran en el dispositivo donde residen sus claves de acceso. Sin embargo, la manipulación de transportes produce resultados inconsistentes: algunas plataformas muestran códigos QR incluso cuando se excluye hybrid, y otras los ocultan sin importar si se incluyen o no. Realice siempre pruebas en las plataformas de destino y proporcione métodos de autenticación alternativos para evitar la creación de callejones sin salida.

Una matriz allowCredentials vacía admite todos los tipos de autenticadores, incluidas las llaves de seguridad y la autenticación entre dispositivos, pero reduce la relevancia del transporte y puede presentar a los usuarios múltiples opciones simultáneas. Al rellenarlo con las credenciales de un usuario específico, el manejo del transporte resulta fundamental para optimizar la interfaz de usuario, lo que permite que los flujos de identificador primero filtren códigos QR en los dispositivos móviles y oculten los avisos de las llaves de seguridad en contextos de consumo.