Capacidades de cliente de WebAuthn

WebAuthn es el estándar moderno detrás de las passkeys. En lugar de depender de las contraseñas tradicionales, aprovecha la criptografía de clave pública, permitiendo a los usuarios autenticarse con passkeys, que pueden incluir datos biométricos (como huellas dactilares o reconocimiento facial) o llaves de seguridad físicas. Este cambio no solo mejora la seguridad, sino que también optimiza la experiencia de usuario al eliminar la necesidad de gestionar contraseñas.

El estándar WebAuthn Nivel 3 introduce nuevas capacidades de cliente (que se pueden obtener a través de la API del navegador getClientCapabilities()), diseñadas para dar a los desarrolladores y a las plataformas más control y flexibilidad al implementar passkeys. Estas actualizaciones traen mejoras que simplifican el proceso de integración de passkeys en diferentes dispositivos, navegadores y plataformas, garantizando un recorrido de usuario más fluido y consistente.

En esta publicación de blog, responderemos a las siguientes preguntas:

1. ¿Qué son las capacidades de cliente de WebAuthn?
2. ¿Qué capacidades de cliente de WebAuthn existen?
3. ¿Cómo mejoran las capacidades de cliente de WebAuthn las implementaciones de passkeys?
4. ¿Por qué son importantes las capacidades de cliente de WebAuthn tanto para los desarrolladores como para los gerentes de producto?

Al final, quedará claro cómo estas características ayudan a crear flujos de autenticación fluidos y seguros que se alinean con las expectativas de los usuarios modernos.

Las capacidades de cliente de WebAuthn son un conjunto de características que permiten a los navegadores y plataformas comunicar qué tipos de funcionalidades de WebAuthn admiten. En términos sencillos, actúan como una "lista de verificación de funciones" que informa a los sitios web qué métodos y configuraciones de autenticación están disponibles en el dispositivo de un usuario. Esto permite a los desarrolladores adaptar los flujos de autenticación en función de las capacidades del cliente, garantizando una experiencia de usuario más fluida y segura.

Por ejemplo, si un navegador indica que admite la autenticación biométrica (como Touch ID), los desarrolladores pueden diseñar sus flujos de inicio de sesión para ofrecer a los usuarios la opción de acceder con su huella dactilar. Por el contrario, si el navegador no admite ciertas funciones, los desarrolladores pueden ofrecer opciones de respaldo, como una contraseña o un OTP por SMS.

El estándar WebAuthn Nivel 3 introduce varias capacidades de cliente nuevas que hacen que las implementaciones de passkeys sean más versátiles y fáciles de usar. El primer soporte para la llamada a la API getClientCapabilities() se introdujo en Safari 17.4.

Para detectar el soporte en el navegador, el siguiente fragmento de código puede ser útil:

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() permite a los sitios web y aplicaciones consultar al cliente (por ejemplo, el navegador o el dispositivo) para determinar qué funciones de WebAuthn admite. Al comprender las capacidades del cliente, los desarrolladores pueden optimizar los flujos de autenticación para aprovechar las funciones disponibles, como la autenticación biométrica, y proporcionar métodos alternativos si ciertas capacidades no están presentes.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Aquí un vistazo más de cerca a las capacidades de cliente de WebAuthn y cómo impactan en la integración de passkeys:

conditionalCreate habilita la creación automática de passkeys según condiciones específicas. Una aplicación podría usar esta capacidad para crear automáticamente una passkey durante el autocompletado de contraseñas si el gestor de contraseñas tiene soporte para ello. Esta característica ayuda a impulsar la adopción de passkeys y su uso posterior al hacer la transición automática de los usuarios de contraseñas a passkeys.

Similar a conditionalCreate, conditionalGet activa los inicios de sesión con passkeys de forma automática. Esto es útil en escenarios donde se debe habilitar la mejor experiencia de usuario para passkeys, haciendo que el inicio de sesión no solo sea sin contraseña, sino también sin nombre de usuario (los usuarios simplemente hacen clic en la passkey seleccionada en un modal/desplegable y pueden autenticarse). Al usar esta capacidad, los desarrolladores pueden asegurar que la autenticación con passkey solo ocurra cuando sea apropiado, minimizando las solicitudes innecesarias y mejorando la experiencia del usuario.

hybridTransport asegura que las passkeys se puedan usar en diferentes dispositivos, habilitando una autenticación entre dispositivos fluida (a través de códigos QR y Bluetooth). Por ejemplo, un usuario podría usar una passkey almacenada en su smartphone para iniciar sesión en un servicio en su ordenador de escritorio. Esta capacidad permite a los usuarios autenticarse de forma segura sin la necesidad de transferir manualmente las passkeys o depender de métodos de inicio de sesión convencionales para cada dispositivo, fomentando una experiencia de autenticación unificada.

Los autenticadores de plataforma, como Windows Hello, Face ID o Touch ID, están integrados directamente en los dispositivos y ofrecen una experiencia de passkey más rápida, fluida y segura al permitir a los usuarios autenticarse con datos biométricos u otro método nativo del dispositivo (p. ej., un patrón de PIN).

Become part of our Passkeys Community for updates & support.

Join

userVerifyingPlatformAuthenticator asegura que la autenticación con passkey involucre la verificación del usuario, como un escaneo activo de huellas dactilares o reconocimiento facial, proporcionando una capa extra de seguridad.

La capacidad relatedOrigins permite una autenticación fluida entre diferentes dominios que pertenecen a la misma organización (p. ej., amazon.com y amazon.de). Por ejemplo, si una empresa gestiona múltiples dominios o tiene diferentes subdominios, los usuarios pueden iniciar sesión una vez y acceder a todas las propiedades sin tener que volver a autenticarse en cada una. Esta capacidad optimiza la experiencia del usuario, reduciendo la fricción, y es especialmente valiosa para empresas en entornos internacionales o con plataformas multiservicio.

El método signalAllAcceptedCredentials(options) proporciona la lista completa de IDs de credencial de WebAuthn para un usuario determinado. Las Relying Parties de WebAuthn deberían usar este método en lugar de signalUnknownCredential() cuando el usuario está autenticado, ya que no hay riesgo de una fuga de privacidad. Este método ofrece una visión completa de las credenciales de clave pública de un usuario, incluyendo cualquier cambio reciente que pueda no haberse actualizado en los autenticadores conectados actualmente.

Veamos un ejemplo. Un usuario (userId: A) tiene 2 passkeys con IDs de credencial que se codifican en Base64URL como X e Y. Luego, el usuario elimina la passkey X en la configuración de la cuenta del servicio web (example.com) (por lo que se elimina la clave pública). Ahora, ejecutamos el siguiente fragmento:

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

Si el autenticador está disponible en el momento de la ejecución del código anterior, entonces el autenticador elimina u oculta la passkey X de futuras ceremonias de autenticación. Sin embargo, es posible que el autenticador no esté conectado en el momento de la ejecución, por lo que se recomienda que las Relying Parties ejecuten este código periódicamente, por ejemplo, en cada inicio de sesión.

Las passkeys que no estén presentes en allAcceptedCredentialIds se eliminarán u ocultarán, potencialmente de forma irreversible. Por lo tanto, es importante que las Relying Parties presten atención para que los IDs de credencial de WebAuthn válidos nunca se eliminen de la lista. Si un ID de credencial válido se eliminó accidentalmente, la Relying Party debe incluirlo inmediatamente en otra llamada a signalAllAcceptedCredentials(options) tan pronto como sea posible para “desocultar” la passkey. Si la passkey no se oculta sino que se elimina, entonces no hay mucho que se pueda hacer para arreglarlo.

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

Try for Free

El método signalCurrentUserDetails(options) señala el nombre actual del usuario y el Display Name de WebAuthn. Cuando se llama a signalCurrentUserDetails(options), el cliente sigue un conjunto de pasos definidos para ejecutar esta acción.

Veamos un ejemplo. Un usuario con el ID de usuario de WebAuthn A actualiza su nombre en la configuración de la cuenta de un sitio web (example.com). Entonces, la Relying Party puede ejecutar el siguiente código:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

El autenticador actualizaría entonces los metadatos de la passkey guardada localmente. El gran beneficio es que en futuras solicitudes de IU condicional / autocompletado de passkeys, el menú de selección / desplegable de la IU condicional muestra el nombre y el Display Name de WebAuthn actualizados.

El método signalUnknownCredential(options) señala que un ID de credencial de WebAuthn no es reconocido por la Relying Party de WebAuthn, por ejemplo, si la passkey fue eliminada por el usuario. A diferencia de signalAllAcceptedCredentials(options), este método no requiere proporcionar la lista completa de IDs de credencial aceptados ni el User Handle de WebAuthn, evitando así posibles fugas de privacidad a llamadores no autenticados.

Veamos un ejemplo. Un usuario elimina una passkey con ID de credencial X en la configuración de la cuenta de un sitio web (example.com) (por lo que se elimina la clave pública). Sin embargo, la clave privada todavía está disponible en el dispositivo del usuario. Esto significa que en futuras solicitudes de inicio de sesión con IU condicional / autocompletado de passkeys (con una lista allowCredentials vacía), la passkey todavía puede ser seleccionada. Sin embargo, el intento de inicio de sesión fallará, ya que la clave pública ya ha sido eliminada, por lo que la Relying Party debería ejecutar:

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

El autenticador entonces eliminaría u ocultaría la passkey con ID de credencial X de futuras ceremonias de autenticación.

Como el estándar WebAuthn Nivel 3 todavía está en estado de borrador, la adopción de estas nuevas capacidades de cliente aún no está completamente extendida. Diferentes navegadores han ido implementando gradualmente estas características, pero el soporte varía. A continuación se muestra un resumen actualizado de la disponibilidad en los principales navegadores mencionados anteriormente:

El ritmo de adopción probablemente se acelerará a medida que el Nivel 3 madure y más navegadores incorporen estas características. Si quieres ver cuántos usuarios pueden aprovechar getClientCapabilities() ahora mismo, puedes consultar datos del mundo real utilizando el Passkeys Analyzer gratuito. Mantente atento a las notas de lanzamiento de los navegadores y la documentación relevante para planificar una compatibilidad más amplia a medida que evoluciona.

Are your users passkey-ready?

Test Passkey-Readiness

Como desarrollador, podrías preguntarte qué significa para ti esta nueva detección de capacidades de cliente de WebAuthn y cómo deberías usarla en tu aplicación. A continuación, encontrarás recomendaciones para usarlas.

Sin embargo, ten en cuenta que no todos los navegadores admiten todavía la llamada a la API getClientCapabilities() (a fecha de noviembre de 2024). Hay un polyfill disponible aquí que se puede usar hasta que todos los navegadores se pongan al día.

Usa getClientCapabilities() al principio de tu código para detectar las funciones admitidas por el cliente al inicio de la carga de la página o del flujo de autenticación. Esto te permitirá personalizar la experiencia dinámicamente y ofrecer las características de passkey que funcionan en el dispositivo/navegador, por ejemplo, impulsando la autenticación de plataforma cuando sea compatible u ofreciendo métodos alternativos (p. ej., OTP por SMS o llaves de seguridad de hardware) si no lo es.

Si añades passkeys a un sitio web o aplicación que actualmente usa contraseñas, la función conditionalCreate puede ser un verdadero impulsor para tu adopción de passkeys. En segundo plano, durante un autocompletado de contraseña con un gestor de credenciales compatible (solo Contraseñas de Apple a fecha de octubre de 2024), se genera automáticamente una passkey que se preferirá en futuros autocompletados.

Para no solo tener una alta adopción de passkeys, sino también un alto uso en el inicio de sesión con passkeys, intenta comprobar si el dispositivo/navegador puede usar la IU condicional / Autocompletado de Passkey verificando conditionalGet. De esta manera, incentivarás a los usuarios a usar la passkey creada para iniciar sesión, ya que es sugerida proactivamente por el sistema operativo/navegador y requiere incluso menos esfuerzo que autocompletar una contraseña.

Utiliza hybridTransport para habilitar la autenticación entre dispositivos (a través de código QR y Bluetooth), permitiendo a los usuarios iniciar sesión sin problemas desde su smartphone, incluso si están accediendo a tu servicio en un ordenador de escritorio.

Las capacidades de cliente de WebAuthn representan un importante paso adelante para abordar las brechas existentes en las passkeys. En esta publicación de blog, hemos abordado preguntas clave sobre las capacidades de cliente de WebAuthn:

1. ¿Qué son las capacidades de cliente de WebAuthn? Explicamos cómo estas características permiten a los navegadores y plataformas señalar su soporte para funcionalidades específicas, dando a los desarrolladores más control sobre los flujos de autenticación.
2. ¿Qué capacidades de cliente de WebAuthn existen? Proporcionamos una visión general de las nuevas capacidades introducidas en el estándar de Nivel 3, incluyendo getClientCapabilities, conditionalCreate, hybridTransport y más.
3. ¿Cómo mejoran las capacidades de cliente de WebAuthn las implementaciones de passkeys? Discutimos cómo estas capacidades optimizan la integración, mejoran el uso entre dispositivos y aumentan la seguridad.
4. ¿Por qué son importantes las capacidades de cliente de WebAuthn para los desarrolladores? Estas características ayudan a crear experiencias de autenticación fluidas y seguras que se alinean con las expectativas de los usuarios modernos, haciendo la implementación más fácil y efectiva.

Te animamos a explorar las nuevas características de WebAuthn Nivel 3 y a mantenerte actualizado sobre su adopción en los navegadores. Si estás buscando implementar passkeys y aprovechar estas capacidades avanzadas, contáctanos para obtener orientación y soporte de expertos.