API Signal de WebAuthn: Actualizar y eliminar passkeys en el lado del cliente

El ecosistema de las passkeys está en constante evolución. Para facilitar este cambio, el estándar WebAuthn subyacente evoluciona rápidamente. Las nuevas funcionalidades suelen comenzar con una explicación técnica en GitHub y luego se convierten en una pull request al estándar una vez que se han discutido lo suficiente. Recientemente, esta pull request se añadió al borrador del estándar como la API Signal de WebAuthn. En este artículo, cubriremos:

• Por qué es necesaria la API Signal de WebAuthn: ¿Qué casos de uso soporta la API Signal de WebAuthn?
• Cómo funciona la API Signal de WebAuthn: ¿Cómo funciona exactamente la API Signal de WebAuthn? ¿Cuáles son las recomendaciones para las relying parties?

En el momento de actualizar esta entrada de blog en enero de 2025, la API Signal de WebAuthn está habilitada por defecto desde Chrome 132 y anteriormente se conocía como la API de Reporting antes de ser renombrada para evitar conflictos con otra API del mismo nombre.

La API Signal de WebAuthn aborda casos de uso específicos relacionados con la gestión de passkeys en el lado del cliente. Específicamente, ayuda a mantener la información sincronizada entre la relying party (RP) y los autenticadores que forman parte de los sistemas operativos del lado del cliente. Existen los siguientes casos de uso importantes:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Cuando se crea una passkey, esta incluye varias piezas de información: user.id, user.name y user.displayName. La passkey en sí se identifica mediante el Credential ID único.

• user.id: es un identificador único que representa la cuenta a la que está vinculada la passkey. Este user.id es crucial porque se utiliza para la correspondencia real de la passkey con la cuenta del usuario.
• user.name y user.displayName: son metadatos que se utilizan únicamente con fines de visualización en la interfaz de usuario.

La siguiente ilustración muestra una estructura de base de datos típica y simple que explica qué información se almacenaría normalmente en cada campo:

Es importante entender que, si bien user.name (a menudo una dirección de correo electrónico) y user.displayName (un nombre más amigable y legible) ayudan al usuario a identificar su cuenta en la interfaz de selección, la verdadera asociación entre una passkey y una cuenta se mantiene a través del user.id y el Credential ID:

• Una cuenta puede tener múltiples passkeys, pero cada passkey se identifica y se asocia de forma única a la cuenta utilizando el user.id.
• Cada passkey tiene un Credential ID único que es generado por el autenticador.

Un problema surge cuando el user.name, que puede ser una dirección de correo electrónico, cambia. Actualmente, no existe un mecanismo para actualizar este cambio directamente en el autenticador del lado del cliente. El user.name puede cambiar por varias razones, como cuando un usuario actualiza su dirección de correo electrónico. A pesar de este cambio en los metadatos de la cuenta en el lado del servidor, el antiguo user.name seguirá apareciendo en la interfaz de selección de credenciales, lo que puede causar confusión a los usuarios.

La solución alternativa para este problema es crear una nueva passkey con el user.name actualizado y el mismo user.id, y luego sobrescribir la passkey existente. Sin embargo, este enfoque es inconveniente por varias razones:

1. Redundancia: Cada user.id solo puede tener una passkey por ID de relying party, lo que significa que la passkey antigua debe ser reemplazada por una nueva, lo cual es un paso adicional.
2. Experiencia de usuario: Los usuarios no entenderán por qué necesitan crear una nueva passkey. Esa es la razón por la que esta solución no está muy extendida.
3. Complejidad: Gestionar la creación de passkeys y su reemplazo solo para actualizar metadatos es una complejidad innecesaria.

Las direcciones de correo electrónico, los números de teléfono y otros identificadores pueden cambiar con regularidad. Sin un método directo para actualizar user.name y user.displayName en el autenticador, los usuarios pueden encontrarse con un problema persistente en el que ven y tienen que seleccionar una passkey asociada a su antigua dirección de correo electrónico. Esta situación socava la experiencia fluida que las passkeys pretenden ofrecer. La API Signal de WebAuthn tiene como objetivo resolver este problema permitiendo a las relying parties informar sobre actualizaciones en los metadatos de las passkeys sin requerir la creación de nuevas. Antes de explicar cómo implementar la API Signal, exploraremos el segundo caso de uso importante que aborda.

Become part of our Passkeys Community for updates & support.

Join

Otro caso de uso crucial es la eliminación de passkeys en el autenticador del lado del cliente. Con el tiempo, los usuarios pueden revocar credenciales a través de la lista de gestión de passkeys o eliminar sus cuentas, y se hace necesario asegurar que estas credenciales se eliminen del autenticador del lado del cliente para evitar que aparezcan en futuras interfaces de selección de credenciales (Conditional UI / autofill de passkeys).

La necesidad de esta funcionalidad surge en varios escenarios:

1. Passkey eliminada a través de la configuración de la cuenta: Cuando una credencial ya no es válida, como después de que un usuario la haya eliminado explícitamente a través de la configuración de la cuenta:

Desde la perspectiva del usuario, es difícil entender que una eliminación en la configuración de su cuenta, en un diálogo como el anterior, no resulte en la eliminación de la passkey en este cliente.

2. Eliminación de la cuenta: Cuando un usuario elimina su cuenta, todas las passkeys asociadas también deberían eliminarse.
3. Políticas de seguridad: Las relying parties pueden tener políticas de seguridad que requieran la revocación de credenciales después de períodos de inactividad o debido a problemas de seguridad detectados.

Sin un método directo para eliminar passkeys en el lado del cliente, estas credenciales obsoletas o no válidas continúan saturando la interfaz de selección, lo que genera confusión. Los usuarios podrían ver e intentar usar passkeys que ya no son válidas, lo que resultaría en intentos de autenticación fallidos y una mala experiencia de usuario.

Implementar la API Signal de WebAuthn implica varios pasos y consideraciones para asegurar que la funcionalidad se integre de manera correcta y segura. La API Signal permite a las relying parties (RPs) actualizar o eliminar credenciales de passkey en el autenticador del lado del cliente. Esta sección describe las consideraciones y los pasos clave para la implementación.

Al implementar la API Signal de WebAuthn, es crucial tener en cuenta las siguientes consideraciones:

• Preservación de la privacidad: La API Signal de WebAuthn está diseñada para preservar la privacidad del usuario, ya que es uno de los fundamentos de WebAuthn. Esto significa que no se proporciona ninguna retroalimentación a la RP sobre si el cambio solicitado se procesó. La API opera de forma silenciosa para evitar cualquier posible fuga de información sobre el estado de las credenciales.

• Disponibilidad del autenticador: La efectividad de la API Signal de WebAuthn depende de la disponibilidad del autenticador. Esto incluye tanto la disponibilidad física (p. ej., la presencia de una llave de seguridad) como el soporte de software (p. ej., compatibilidad del navegador y del sistema operativo). El navegador solo puede realizar acciones si el autenticador es accesible y soporta las operaciones necesarias sin necesidad de autenticación biométrica.

• Restricciones de dominio: La API asegura que solo la relying party asociada con un dominio específico pueda solicitar cambios en las credenciales relacionadas con ese dominio. Esta es una medida de seguridad para prevenir modificaciones no autorizadas por parte de terceros.

• El Credential ID como clave: Al hacer referencia a las passkeys, el Credential ID es la clave principal utilizada por la API Signal de WebAuthn. Este ID identifica de forma única la passkey en el autenticador del lado del cliente. La API permite a las RPs cambiar los metadatos asociados con las passkeys o señalar que ciertas passkeys ya no deben ser accedidas, pero solo a través del Credential ID. En caso de que un autenticador no conozca un Credential ID específico, lo ignorará silenciosamente.

Estas consideraciones son esenciales para entender los aspectos más importantes del correcto funcionamiento de la API Signal de WebAuthn.

La API Signal de WebAuthn proporciona un mecanismo simplificado para que las relying parties (RPs) actualicen los metadatos asociados con las passkeys en los autenticadores del lado del cliente. Esto es especialmente importante para asegurar que los usuarios vean información precisa y actualizada en la interfaz de selección de credenciales sin tener que crear nuevas passkeys innecesariamente. Así es como la API permite que esto suceda:

Actualización de metadatos con signalCurrentUserDetails(options)

El método signalCurrentUserDetails(options) en la API Signal está diseñado específicamente para actualizar los metadatos de las passkeys. Este método permite a las RPs proporcionar los valores actuales para user.name y user.displayName.

Así es como funciona el proceso (ver también el estándar WebAuthn Nivel 3).

1. Estructura del método: El método signalCurrentUserDetails(options) incluye el rp.id, el user.id y los valores actualizados para user.name y user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Actualización de los metadatos locales: Busca las credenciales disponibles localmente (en el autenticador) que coincidan con el rpId y el userId. Para todas las credenciales coincidentes, el autenticador actualizará el name y el displayName de la credencial.

3. Preservación de la privacidad: El proceso está diseñado para preservar la privacidad. La API Signal no proporciona retroalimentación a la RP sobre si las actualizaciones se procesaron con éxito, evitando cualquier fuga de información sobre el estado de las credenciales.

4. Consistencia entre dispositivos: Al ejecutar regularmente los métodos signalCurrentUserDetails(options), las RPs pueden asegurar que los metadatos de las passkeys se mantengan consistentes en diferentes dispositivos y plataformas donde el usuario pueda autenticarse. Este enfoque reduce las posibilidades de que se muestre información obsoleta o incorrecta en la interfaz de selección de credenciales.

En la captura de pantalla anterior, se puede ver cómo Google Chrome le señala dicha actualización al usuario. La API Signal de WebAuthn forma parte de Chrome 130 y se puede probar con el Administrador de contraseñas de Google en el escritorio si la bandera de características web experimentales está activada.

La API Signal de WebAuthn proporciona mecanismos para que las relying parties (RPs) señalen la eliminación de passkeys de los autenticadores del lado del cliente. Esto es esencial para asegurar que las credenciales obsoletas o no válidas no aparezcan en la interfaz de selección de credenciales, manteniendo así una experiencia de usuario optimizada y segura. Hay dos métodos para eliminar las passkeys localmente: signalUnknownCredential(options) y signalAllAcceptedCredentials(options). El primero se puede usar en situaciones en las que el usuario no está autenticado, mientras que el segundo se puede usar cuando el usuario está autenticado. Por lo tanto, este último debería preferirse por razones de privacidad.

Así es como funcionan los dos métodos:

1. Estructura del método: El método signalUnknownCredential(options) incluye el rpId (ID de la relying party) y el credentialId (el identificador único de la credencial a eliminar).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Llamada al método: Las RPs llaman a este método cada vez que detectan que una credencial debe ser eliminada. Esto podría ser inmediatamente después de un intento de autenticación con una credencial no válida, durante la eliminación de una cuenta o cuando un usuario revoca una credencial a través de la configuración de la cuenta.

3. Manejo del método: Cuando se llama al método signalUnknownCredential(options), el autenticador del lado del cliente intenta encontrar las credenciales que coinciden con el rpId y el credentialID especificados para su omisión. Dependiendo de las capacidades del autenticador, la credencial se elimina o se emplea un procedimiento específico del autenticador para ocultar la credencial en futuras ceremonias de autenticación.

1. Estructura del método: El método signalAllAcceptedCredentials(options) incluye el rpId (ID de la relying party), el userId y una lista de Credential IDs válidos allAcceptedCredentialIds (lista de identificadores únicos de credenciales que deben conservarse).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Llamada al método: Las RPs llaman a este método cada vez que detectan que una credencial debe ser eliminada y señalan una lista de credenciales válidas. Este método debe preferirse sobre signalUnknownCredential(options) para eliminar credenciales.

3. Manejo del método: Cuando se llama al método signalAllAcceptedCredentials(options), el autenticador del lado del cliente busca coincidencias con el rpId y el userId. El autenticador busca todas las credenciales locales que coinciden con rpId y userId. El resultado se compara con allAcceptedCredentialIds. Si hay credenciales locales que no están en allAcceptedCredentialIds, estas se eliminan localmente (o se ocultan, dependiendo del autenticador).

4. Mostrar credenciales ocultas: Si las credenciales solo se han ocultado (dependiendo del autenticador) y ahora forman parte de allAcceptedCredentialIds, entonces estas credenciales volverán a estar presentes en futuras ceremonias de autenticación.

5. Consejos útiles:

   • Al usar signalAllAcceptedCredentials(options), es importante tener en cuenta que los autenticadores no siempre estarán conectados en el momento en que se ejecuta este método. Como resultado, las relying parties podrían considerar ejecutar signalAllAcceptedCredentials(options) periódicamente, como durante cada inicio de sesión, para asegurar que todas las credenciales estén actualizadas.
   • Las relying parties deben ser cautelosas al especificar la lista de IDs de credenciales (allAcceptedCredentialIds). Las credenciales que no se incluyan en esta lista pueden ser ocultadas o eliminadas por el autenticador, potencialmente de forma irreversible. Para evitar que se omitan por error credenciales válidas, es crucial asegurarse de que la lista esté completa. Si un ID de credencial válido se omite accidentalmente, debe volver a añadirse a signalAllAcceptedCredentials(options) lo antes posible para que vuelva a ser visible, suponiendo que el autenticador lo soporte.
   • Siempre que sea posible, los autenticadores deberían preferir ocultar temporalmente las credenciales en lugar de eliminarlas permanentemente. Este enfoque puede ayudar a facilitar la recuperación si una relying party omitió accidentalmente un ID de credencial válido, permitiendo que se restaure sin una pérdida permanente.

En la captura de pantalla anterior, se puede ver cómo Google Chrome señala las eliminaciones. La API Signal de WebAuthn forma parte de Chrome 132 y se puede probar con el Administrador de contraseñas de Google en el escritorio.

Para implementar eficazmente la API Signal de WebAuthn y asegurar una sincronización fluida de los metadatos de las passkeys en los autenticadores del lado del cliente, considere las siguientes recomendaciones:

• Estar atentos a las actualizaciones y a la implementación real de la API Signal de WebAuthn: Manténgase informado sobre los últimos desarrollos y actualizaciones relacionados con la API Signal. La API Signal de WebAuthn está habilitada con Google Chrome 132, y será seguida por otros navegadores (p. ej., Safari también anunció su soporte). Revise regularmente el progreso y las actualizaciones de la API Signal de WebAuthn para asegurar que su implementación se alinee con los últimos estándares y prácticas. Actualizaremos esta entrada de blog en el futuro; actualmente se basa en la información disponible a 14 de enero de 2025.
• Comenzar con el enfoque de signalAllAcceptedCredentials(options) después de cada inicio de sesión exitoso: Este enfoque asegura que todos los metadatos y los IDs de credenciales se actualicen en un solo método, simplificando el proceso y manteniendo la consistencia entre dispositivos y plataformas, y al mismo tiempo desactiva las credenciales eliminadas u obsoletas.
• Mensajería en tiempo real con signalUnknownCredential(options) para implementaciones a gran escala: Considere usar mensajería en tiempo real con el método signalUnknownCredential(options) en implementaciones a gran escala o cuando haya necesidad de actualizaciones inmediatas. Este método puede mejorar la eficiencia y la precisión de la gestión de credenciales, asegurando que las credenciales no válidas u obsoletas se eliminen rápidamente de la interfaz de selección.

Siguiendo estas recomendaciones, podrá implementar la API Signal de WebAuthn de manera efectiva una vez que esté soportada, asegurando que los metadatos de las passkeys se mantengan actualizados y consistentes en todos los autenticadores del lado del cliente, proporcionando así una experiencia de usuario fluida y segura para las passkeys.

El estándar WebAuthn evoluciona continuamente, enriqueciéndose con nuevas funcionalidades cada mes. La introducción de la API Signal de WebAuthn es un paso significativo en la gestión de los metadatos y las eliminaciones de passkeys en los autenticadores del lado del cliente. Esta API aborda los casos de uso cruciales de mantener la información sincronizada entre las relying parties (RPs) y los autenticadores, y de asegurar que las passkeys no válidas u obsoletas se eliminen, mejorando así la experiencia del usuario.

• ¿Por qué es necesaria la API Signal? La API Signal es esencial para actualizar los metadatos de las passkeys y eliminarlas en los autenticadores del lado del cliente. Resuelve problemas relacionados con información obsoleta de user.name y user.displayName, que puede causar confusión cuando las credenciales se presentan en la interfaz de selección. Además, ayuda a mantener una interfaz de selección de credenciales limpia y segura al eliminar las passkeys revocadas o eliminadas.
• ¿Cómo funciona la API Signal? La API Signal funciona permitiendo a las RPs llamar a métodos sobre el estado actual de las credenciales, incluyendo actualizaciones de metadatos y la señalización de la eliminación de passkeys. Estos informes son procesados por el autenticador del lado del cliente, asegurando que la información presentada a los usuarios sea precisa y actualizada. La API está diseñada para preservar la privacidad y opera sin proporcionar retroalimentación a la RP sobre el éxito de las actualizaciones.

A medida que el estándar WebAuthn evoluciona, se beneficia de los diversos intereses de sus participantes, que impulsan diferentes partes del estándar. Mantenerse al tanto de estos desarrollos es crucial para estar al día con las últimas mejoras y asegurar que las implementaciones sigan alineadas con las mejores prácticas y estándares más recientes. La comunidad de WebAuthn sigue impulsando la innovación, haciendo que la autenticación sea más segura y fácil de usar.