Transportes de WebAuthn: Transporte interno e híbrido

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

Get free Whitepaper

Nota: Según la especificación de WebAuthn, un array de transportes vacío significa que todos los transportes son compatibles.

Al implementar passkeys en distintas plataformas, nos enfrentamos como desarrolladores a una decisión importante:

• ¿Cómo debemos gestionar los transportes de WebAuthn, especialmente los internos e híbridos, para garantizar una experiencia de autenticación óptima entre dispositivos?

La respuesta está en entender los transportes de WebAuthn, un detalle técnico que determina cómo los autenticadores se comunican con las relying parties. Aunque los transportes parecen sencillos en teoría, su implementación varía significativamente entre los navegadores web, las aplicaciones nativas de iOS y las de Android, sobre todo en lo que respecta al manejo de los 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 gestionar los transportes internos e híbridos, cada uno con sus propias ventajas y desventajas.

Este artículo cubre:

1. Transportes de WebAuthn: interno, híbrido y autenticadores de plataforma en la web, iOS y Android
2. Dos enfoques: manejo de transportes interno e híbrido conforme a la especificación vs. optimizado
3. Mejores prácticas y recomendaciones para la implementación de la 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 las YubiKeys u otros tokens de seguridad FIDO2.

nfc: Permite la comunicación con autenticadores a través de Near Field Communication, lo que permite a los usuarios tocar sus llaves de seguridad o dispositivos con NFC.

ble: Facilita la autenticación a través de Bluetooth de baja energía, permitiendo la comunicación inalámbrica con autenticadores externos.

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

hybrid: Permite la autenticación entre dispositivos, típicamente donde un usuario escanea un código QR para autenticarse entre dispositivos, como usar un teléfono para autenticarse en un navegador de escritorio, o viceversa. Este transporte puede activar la solicitud de código QR tanto en dispositivos de escritorio como móviles, lo que no siempre es deseable según el contexto. Nota: hybrid se añadió en WebAuthn Nivel 3.

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

Cuando se crea un passkey, el autenticador indica qué transportes admite. Esta información se envía a la relying party (tu backend), que debería guardarla junto con la credencial. Durante la autenticación, la relying party envía estos transportes de vuelta al cliente en la lista allowCredentials, ayudando al navegador o a la plataforma a determinar qué métodos de autenticación ofrecer al usuario.

El manejo de los transportes difiere significativamente entre plataformas, lo que crea los desafíos de compatibilidad a los que se enfrentan los desarrolladores.

Los navegadores reciben la información de transporte de los autenticadores y la respetan durante los flujos de autenticación. Cuando creas un passkey en Chrome, Safari o Edge, el gestor de credenciales del navegador proporciona datos de transporte que varían según el autenticador subyacente:

Autenticadores de plataforma: Windows Hello proporciona solo ["internal"], reflejando su naturaleza vinculada al dispositivo. Sin embargo, cuando Chrome utiliza 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"] según sus capacidades reales.

Gestores de credenciales sincronizados en la nube: iCloud Keychain 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 fiable en contextos web, aunque los transportes específicos dependen del autenticador que el navegador seleccione para almacenar las credenciales.

Documentación: Especificación de WebAuthn del W3C

La API Credential Manager de Android se comporta de manera similar a los navegadores web. Al crear passkeys en aplicaciones nativas de Android, el Credential Manager 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 forma consistente. Los desarrolladores de Android pueden confiar en esta información sin necesidad de un manejo especial.

Documentación: Android Credential Manager

iOS presenta una situación más compleja. El framework AuthenticationServices de Apple maneja los transportes de manera diferente según el tipo de autenticador:

Autenticadores de plataforma (iCloud Keychain, verificado mediante Face ID o Touch ID): A menudo devuelven arrays de transportes vacíos durante la creación de passkeys. Esto no significa que el passkey carezca de capacidades de transporte, simplemente que iOS no las informa explícitamente. Según el estándar WebAuthn, omitir los transportes significa que cualquier transporte es aceptable, por lo que la autenticación híbrida seguirá funcionando.

Llaves de seguridad: Sí proporcionan información de transporte (p. ej., ["usb"], ["nfc"]) cuando se usan con dispositivos iOS, siguiendo el patrón esperado.

Documentación: AuthenticationServices de Apple

Como desarrolladores, nos enfrentamos a una elección: seguir la especificación estrictamente u optimizar los transportes internos e híbridos para la experiencia del usuario. Cada enfoque tiene sus ventajas y desventajas.

Este enfoque se alinea con la especificación de WebAuthn: usar los transportes exactamente como los proporciona el autenticador durante el registro de la credencial y enviarlos de vuelta sin cambios durante la autenticación.

Implementación: Cuando se crea un passkey, guarda el array transports de la respuesta del autenticador. Durante la autenticación, incluye estos transportes exactos en la lista allowCredentials:

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

Ventajas:

• Conformidad con la especificación: Sigue los estándares de WebAuthn con precisión, asegurando la compatibilidad con futuras actualizaciones de las plataformas.
• Fiabilidad de las llaves de seguridad: Funciona perfectamente para las 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 del array vacío en iOS: Los autenticadores de plataforma en iOS devuelven transportes vacíos, lo que según la especificación significa "cualquier transporte", pudiendo mostrar todas las opciones de autenticación, incluidas las llaves de seguridad.
• 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: Diferentes plataformas ofrecen diferentes opciones de autenticación para la misma cuenta.

Ideal para: Aplicaciones que priorizan la conformidad con los estándares, entornos empresariales con diversos tipos de autenticadores.

Este enfoque prioriza la experiencia del usuario modificando selectivamente los transportes internos e híbridos en función de objetivos de optimización específicos. En lugar de una regla general, consideremos estos escenarios de optimización comunes:

Problema: Los autenticadores de plataforma de iOS devuelven arrays de transportes vacíos. Si se dejan vacíos o se rellenan desde el backend, los usuarios podrían ver solicitudes de llaves de seguridad (USB, NFC) junto a las opciones de plataforma, creando confusión en las aplicaciones de consumo.

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

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

Resultado: Una interfaz de autenticación limpia sin solicitudes de llaves de seguridad para los passkeys creados en iOS.

Problema: Al autenticarse en dispositivos móviles, mostrar códigos QR para la autenticación entre dispositivos crea una mala experiencia de usuario, ya que los usuarios ya están en un dispositivo móvil con sus passkeys disponibles.

Solución: Eliminar 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 móviles ven solo opciones de autenticación directa sin solicitudes innecesarias de código QR.

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

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

Riesgo de callejones sin salida: Un filtrado de transportes demasiado restrictivo puede crear callejones sin salida en la autenticación, donde los usuarios no pueden iniciar sesión en absoluto. Por ejemplo, eliminar hybrid podría impedir escenarios legítimos de autenticación entre dispositivos en los que un usuario necesita autenticarse desde un dispositivo prestado. Proporciona siempre métodos de autenticación alternativos y realiza pruebas exhaustivas en tus plataformas de destino antes de implementar optimizaciones de transporte.

Estas son sugerencias de optimización: WebAuthn proporciona otros mecanismos para optimizar la experiencia de usuario de la autenticación más allá de la manipulación de transportes, como las sugerencias (hints).

El comportamiento de los transportes es impredecible: La autenticación entre dispositivos (CDA) a través del transporte hybrid muestra un comportamiento inconsistente en las distintas 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 explícitamente los transportes, debes tener en cuenta las diferencias entre plataformas:

• iOS: Envía arrays vacíos para los autenticadores de plataforma; requiere rellenarlos.
• Windows Hello: Debe permanecer solo como ["internal"]; añadir hybrid activa códigos QR no deseados.
• Web y Android: Generalmente proporcionan información de transporte precisa.
• Variaciones de CDA: Las solicitudes de código QR pueden aparecer o desaparecer independientemente de la presencia de hybrid en el array de transportes.

Se requiere una comprensión completa: Controlar explícitamente los transportes significa asumir la responsabilidad de todo el flujo. Debes entender cómo se comporta cada combinación de transporte en todas tus plataformas de destino y realizar pruebas exhaustivas. La manipulación de transportes puede crear callejones sin salida en la autenticación donde no existe una ruta de autenticación válida para los usuarios.

Ventajas:

• Experiencia de usuario a medida: Controla exactamente qué opciones de autenticación ven los usuarios en contextos específicos.
• Resuelve el problema del array vacío de iOS: Define explícitamente los transportes donde iOS no proporciona ninguno.
• Optimización según el contexto: Adapta la interfaz de usuario de autenticación según el tipo de dispositivo.

Desventajas:

• Comportamiento impredecible: La manipulación de transportes no garantiza un comportamiento consistente de la interfaz de usuario; pruebas exhaustivas muestran que las plataformas interpretan los transportes de manera diferente, a veces mostrando u ocultando opciones independientemente de los valores de transporte.
• Riesgo de callejones sin salida en la autenticación: Un filtrado de transportes demasiado restrictivo puede impedir 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 la especificación, lo que podría causar problemas con futuros cambios en las plataformas.
• Carga de mantenimiento: Requiere una lógica y actualizaciones continuas específicas para cada plataforma a medida que estas evolucionan.
• Complejidad: Se deben manejar manualmente los arrays vacíos de iOS, las restricciones de Windows Hello y otras peculiaridades de las plataformas.
• Sobrecarga de pruebas: Cada regla de optimización necesita ser verificada en todas las combinaciones de plataformas.

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

El manejo de los transportes de WebAuthn no existe de forma aislada; es una pieza de tu estrategia general de implementación de passkeys. Surgen dos enfoques comunes en las implementaciones en producción, cada uno con diferentes implicaciones para el uso de transportes internos e híbridos.

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

Características de la implementación:

• Interfaz de autenticación: El botón de passkey aparece junto a las opciones de inicio de sesión existentes (nombre de usuario/contraseña).
• allowCredentials: Se establece como un array vacío [], permitiendo que cualquier credencial coincida.
• Tipos de autenticador: Se admiten llaves de seguridad, autenticación entre dispositivos (códigos QR) y autenticadores de plataforma.
• Requisitos de la aplicación nativa: Debe admitir todos los métodos de autenticación, incluidas las llaves de seguridad.
• preferImmediatelyAvailableCredentials: No se puede usar, ya que excluye por definición las llaves de seguridad y los inicios de sesión con código QR.
• Manejo de transportes: Debe admitir todos los tipos de transporte, incluidos los de las llaves de seguridad (usb, nfc, ble).

Implicaciones para los transportes:

Con un allowCredentials vacío, 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 simultáneamente solicitudes de llaves de seguridad, códigos QR y opciones de plataforma, lo que puede crear una parálisis por decisión en las aplicaciones de consumo.

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

Este enfoque optimiza la experiencia de usuario para el consumidor restringiendo la creación de passkeys a los autenticadores de plataforma y utilizando flujos de "primero el identificador".

Características de la implementación:

• Creación de passkeys: Solo se permiten autenticadores de plataforma a través de authenticatorAttachment: "platform".
• Flujo de autenticación: Primero el identificador: los usuarios introducen su correo electrónico/nombre de usuario antes de la autenticación.
• allowCredentials: Se rellena con las credenciales específicas del usuario (no vacío) una vez que se conoce el identificador.
• Tipos de autenticador: Autenticadores de plataforma y autenticación entre dispositivos; las llaves de seguridad suelen excluirse.
• Optimización de la aplicación nativa: Se puede usar preferImmediatelyAvailableCredentials, que excluye por definición las llaves de seguridad y la autenticación entre dispositivos.
• Autenticación entre dispositivos: Disponible en la web; no disponible al usar preferImmediatelyAvailableCredentials en aplicaciones nativas, pero este escenario es raro (los usuarios suelen tener los passkeys en el dispositivo que están usando).
• Manejo de transportes: Centrado únicamente en los transportes internal e hybrid.

Implicaciones para los transportes:

Dado que allowCredentials contiene credenciales específicas con sus transportes, el manejo de estos se vuelve crucial.

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

Para plataformas que ya revelan la existencia de una cuenta o utilizan flujos de "primero el identificador" (el usuario introduce el correo electrónico antes de ver las opciones de inicio de sesión), el enfoque adaptado al consumidor se alinea de forma natural. Una vez que el usuario ha proporcionado su identificador:

1. El backend busca los passkeys existentes.
2. Devuelve allowCredentials con credenciales específicas y sus transportes.
3. La plataforma puede optimizar la interfaz de usuario de autenticación basándose en los transportes.
4. No hay riesgo adicional de enumeración de cuentas (el identificador ya se ha proporcionado).

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

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

Independientemente del enfoque que elijas para gestionar los transportes internos e híbridos, sigue estas prácticas para minimizar problemas:

Guarda los transportes durante el registro: Almacena siempre el array transports de la respuesta del autenticador junto con el ID de la credencial y la clave pública. Estos datos son esenciales para los flujos de autenticación.

Maneja los arrays vacíos con elegancia: Cuando recibas un array de transportes vacío de los autenticadores de plataforma de iOS:

• Conforme a la especificación: Déjalo vacío u omite la propiedad de transportes, lo que significa que "cualquier transporte" es aceptable.
• Enfoque de optimización: Rellénalo con ["internal", "hybrid"] para controlar qué opciones de autenticación se muestran.

Realiza pruebas en todas las plataformas de destino: Crea una matriz de pruebas que cubra todas las combinaciones:

• Registro: Web, iOS Nativo, Android Nativo
• Autenticación: Web, iOS Nativo, Android Nativo
• Verifica que los códigos QR aparezcan cuando se espera y se oculten cuando no sea apropiado.

Entiende la diferencia entre un array vacío y una propiedad ausente: Tanto un array de transportes vacío [] como una propiedad de transportes ausente suelen tratarse como "cualquier transporte es aceptable" según la especificación. Sin embargo, los detalles de implementación varían entre plataformas.

Supervisa los cambios en las plataformas: Las implementaciones de WebAuthn evolucionan. Apple, Google y Microsoft actualizan regularmente el comportamiento de sus autenticadores. Mantente informado sobre los cambios que puedan afectar al manejo de los transportes.

Los transportes de WebAuthn, especialmente los internos e híbridos, son detalles técnicos con un impacto práctico significativo en la autenticación entre dispositivos. Tu estrategia de manejo de transportes debe alinearse con tu enfoque general de implementación de passkeys y tus plataformas de destino.

Las decisiones sobre transportes forman parte de una estrategia más amplia: La forma en que manejas los transportes depende de si buscas la máxima flexibilidad (con allowCredentials vacío) o una experiencia de usuario adaptada al consumidor (primero el identificador con credenciales específicas). Esta última opción hace que los transportes sean cruciales para la optimización.

Las diferencias entre plataformas requieren un manejo específico: La web y Android proporcionan información de transporte fiable, mientras que los autenticadores de plataforma de iOS devuelven arrays vacíos. Windows Hello solo envía ["internal"]. Entender estas diferencias es esencial para las implementaciones en producción.

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

El flujo de "primero el identificador" permite la optimización de transportes: Cuando los usuarios proporcionan primero su identificador, el manejo de transportes se convierte en una potente herramienta de experiencia de usuario. Puedes evitar códigos QR no deseados en móviles, ocultar opciones de llaves de seguridad y simplificar la autenticación, sin preocupaciones adicionales de enumeración de cuentas.

Para empresas / Máxima flexibilidad:

• Usa un allowCredentials vacío para admitir todos los tipos de autenticadores.
• Confía en los transportes proporcionados por el autenticador.
• Acepta que los usuarios vean más opciones de autenticación.
• Implementación más sencilla, mayor compatibilidad.

Para aplicaciones de consumo / Aplicaciones nativas:

• Implementa un flujo de autenticación de "primero el identificador".
• Restringe a los autenticadores de plataforma (authenticatorAttachment: "platform").
• Usa allowCredentials con credenciales específicas y transportes optimizados.
• Habilita preferImmediatelyAvailableCredentials en aplicaciones nativas.
• Rellena los arrays vacíos de iOS con ["hybrid", "internal"].
• Filtra hybrid en dispositivos móviles para evitar códigos QR.
• Experiencia de usuario superior con opciones de autenticación simplificadas.

Para plataformas que ya tienen flujos de "primero el identificador":

• La enumeración de cuentas ya no es un problema.
• El enfoque adaptado al consumidor se alinea de forma natural con la experiencia de usuario existente.
• La optimización de transportes proporciona beneficios inmediatos en la experiencia de usuario.
• Es el enfoque recomendado para la mayoría de las aplicaciones de consumo.

Comienza con el enfoque conforme a la especificación y luego optimiza según tu estrategia:

1. Guarda los transportes exactamente como se reciben durante el registro.
2. Decide tu estrategia general (máxima flexibilidad vs. adaptada al consumidor).
3. Si es adaptada al consumidor: implementa el flujo de "primero el identificador" y optimiza los transportes.
4. Maneja los arrays vacíos de iOS de forma apropiada para la estrategia elegida.
5. Realiza pruebas exhaustivas en las plataformas web, iOS nativo y Android nativo.

El panorama de WebAuthn sigue evolucionando. Los proveedores de plataformas actualizan regularmente sus implementaciones y especificaciones como WebAuthn Nivel 3 introducen nuevas capacidades. Construir sistemas flexibles que alineen el manejo de transportes con tu estrategia de autenticación más amplia garantiza que tu implementación de passkeys se mantenga robusta y ofrezca excelentes experiencias de usuario a medida que el ecosistema madura.