Explicación técnica de la Conditional UI de WebAuthn (autocompletar claves de acceso)

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

Obtener cheat sheet

Con la rápida adopción de las claves de acceso (y el protocolo subyacente WebAuthn), la autenticación se ha vuelto más segura y fácil de usar para muchos usuarios. Uno de los avances más destacados de las claves de acceso ha sido la integración de la Conditional UI, a menudo denominada "autocompletar clave de acceso" o Conditional Mediation (en lo sucesivo, mantendremos el término Conditional UI).

A pesar de su reciente introducción y su continua adopción por parte de los navegadores, existe una brecha notable en la documentación técnica y los consejos de implementación para la Conditional UI. Este artículo tiene como objetivo cerrar esa brecha explicando qué es la Conditional UI, cómo funciona y cómo abordar los desafíos comunes durante su implementación.

La Conditional UI representa un nuevo modo para los procesos de inicio de sesión con claves de acceso / WebAuthn. Muestra selectivamente claves de acceso en una interfaz de usuario (UI) solo cuando un usuario tiene una credencial descubrible (clave residente), que es un tipo de clave de acceso, registrada con el relying party (el servicio en línea) y almacenada en el autenticador de un dispositivo (por ejemplo, computadora portátil, teléfono inteligente). Las claves de acceso se muestran en un menú desplegable de selección que se mezcla con las contraseñas autocompletadas, proporcionando una transición fluida entre los sistemas de contraseñas tradicionales y la autenticación avanzada con claves de acceso, ya que los usuarios ven ambos en el mismo contexto. Este enfoque inteligente garantiza que los usuarios no se sientan abrumados con opciones innecesarias y puedan navegar por el proceso de inicio de sesión de manera más fluida.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

La base de la Conditional UI se construye sobre tres pilares principales:

1. Respetar la privacidad del usuario: Garantizar la privacidad del usuario evitando la divulgación de credenciales disponibles o la falta de consentimiento del usuario para revelar estas credenciales.
2. Excelente experiencia de usuario incluso si no existe ninguna clave de acceso: Capacitar a los relying parties para implementar WebAuthn de manera oportunista, asegurando que la experiencia del usuario siga siendo buena incluso si las claves de acceso no están disponibles.
3. Transición fluida de contraseñas a claves de acceso: Combinar claves de acceso con autenticación basada en contraseña para facilitar la transición hacia métodos de autenticación sin contraseña, capitalizando los paradigmas de UX familiares para los usuarios.

• Autenticación simplificada: El proceso es más ágil y eficiente, eliminando las complejidades a menudo asociadas con múltiples métodos de autenticación.
• Reducción de errores de los usuarios: Al presentar solo las opciones relevantes, es menos probable que los usuarios cometan errores durante el proceso de autenticación.
• Mejora de la satisfacción del usuario: Eliminar pasos innecesarios significa que los usuarios pueden iniciar sesión más rápido y sin esfuerzo, lo que lleva a una mayor satisfacción.
• Integración sencilla en el frontend: Una de las características más destacadas de la Conditional UI es su facilidad de integración. Los desarrolladores pueden incorporarla de manera fluida en el frontend con unas pocas líneas de código (ver a continuación).
• Inicio de sesión sin contraseñas y sin nombres de usuario: Uno de los grandes beneficios es que la Conditional UI promueve no solo la autenticación sin contraseña, sino también una experiencia sin nombre de usuario o sin cuenta. A los usuarios se les ahorra la carga mental de recordar su dirección de correo electrónico específica o identificador de usuario del registro. En su lugar, pueden confiar en las sugerencias de los navegadores, que incluyen la dirección de correo electrónico / identificador de usuario emparejado con la clave de acceso adecuada en el menú de autocompletado.
• Resolver el dilema de arranque: La transición de los sistemas tradicionales de nombre de usuario y contraseña a claves de acceso puede ser abrumadora. La Conditional UI aborda este desafío de transición. Los sitios web pueden iniciar una llamada de clave de acceso / WebAuthn junto con un mensaje de contraseña convencional sin preocuparse por los posibles errores del cuadro de diálogo modal si un dispositivo carece de las credenciales necesarias.

Suscríbete a nuestro Substack de passkeys para recibir las últimas noticias.

Suscribirse

• Curva de aprendizaje para desarrolladores: La Conditional UI introduce un nuevo paradigma, lo que significa que hay una curva de aprendizaje involucrada para los desarrolladores no familiarizados con sus complejidades.
• Dependencia de dispositivo / navegador: El éxito de la Conditional UI depende de la compatibilidad del dispositivo o navegador del usuario. Dado que no todos los navegadores o dispositivos la admiten actualmente, esto puede limitar su aplicación.
• Los gestores de contraseñas desactivan el autocompletado: Algunos gestores de contraseñas modernos y sus extensiones de navegador modifican el DOM de los sitios web y desactivan o sobrescriben la etiqueta de autocompletado en los campos de entrada a favor de sus propias funciones de autocompletado. Esto puede llevar a una experiencia de usuario inconsistente e insatisfactoria. Como los estándares para la Conditional UI son relativamente nuevos, esperamos que las cosas mejoren, para que, por ejemplo, no se superpongan dos menús de autocompletado o el deseado no se muestre en absoluto.

A continuación, proporcionamos un desglose paso a paso de las etapas individuales de un flujo completo de Conditional UI:

En general, el flujo del proceso de la Conditional UI se puede dividir en dos fases. Durante la fase de carga de la página, la lógica de la Conditional UI ocurre en segundo plano, mientras que en la fase de operación del usuario, el usuario tiene que hacer algo activamente.

1. Verificación de disponibilidad de la Conditional UI: El cliente (navegador) llama a la función isConditionalMediationAvailable() para detectar si la combinación actual de navegador / dispositivo admite la Conditional UI. Solo si la respuesta es verdadera, el proceso continúa; de lo contrario, se aborta el proceso de Conditional UI.
2. Llamar al endpoint de Conditional UI: A continuación, el cliente llama al endpoint de Conditional UI del servidor para recuperar las PublicKeyCredentialRequestOptions.
3. Recibir PublicKeyCredentialRequestOptions: El servidor devuelve las PublicKeyCredentialRequestOptions que contienen el desafío y más opciones del servidor WebAuthn (por ejemplo, allowCredentials, extensions, userVerification).
4. Iniciar la autenticación local: Al llamar a credentials.get() con las PublicKeyCredentialRequestOptions recibidas y la propiedad mediation establecida en conditional, comienza el proceso para la autenticación local en el dispositivo.
5. Mostrar selección de autocompletado: Aparece el menú de autocompletado para claves de acceso. El estilo específico depende del navegador y el dispositivo (por ejemplo, algunos requieren que el usuario coloque el cursor en el campo de entrada, algunos muestran automáticamente el menú al cargar la página, ver a continuación).
6. Autenticación local del usuario: El usuario selecciona la clave de acceso del menú de autocompletado que desea utilizar y se autentica a través del cuadro de diálogo de autenticación de su dispositivo (por ejemplo, mediante Face ID, Touch ID, Windows Hello).
7. Enviar respuesta del autenticador al servidor: Si la autenticación local del usuario fue exitosa, la respuesta del autenticador se envía de vuelta al servidor.
8. El usuario inicia sesión y es redirigido: Una vez que el servidor recibe la respuesta del autenticador, valida la firma contra la clave pública correspondiente de la cuenta de usuario en la base de datos. Si la verificación es exitosa, se concede acceso al usuario, se inicia sesión y se redirige a la página de inicio de sesión.

Al seguir este flujo de proceso, la Conditional UI ofrece una experiencia de autenticación fluida y amigable para el usuario.

Para que la Conditional UI funcione, se deben considerar algunos aspectos generales:

• Especificaciones de credenciales: La Conditional UI está diseñada específicamente para operar solo con claves residentes / credenciales descubribles. La razón de esto es que los autenticadores no almacenan datos específicos del usuario (por ejemplo, nombre, nombre para mostrar) para claves no residentes / credenciales no descubribles. Como resultado, no es posible utilizar estas últimas para el autocompletado de claves de acceso.
• Filtrado de credenciales: La función allowCredentials sigue siendo compatible, lo que facilita que los sitios web que ya conocen la identidad del usuario (por ejemplo, si se envió un nombre de usuario en la llamada de mediación inicial porque podría estar almacenado en el LocalStorage del navegador) refinen la lista de credenciales que se muestran a los usuarios durante el autocompletado.

Forma parte de nuestra comunidad de passkeys para recibir novedades y soporte.

Unirse

Para que la Conditional UI funcione en el lado del cliente, se deben cumplir los siguientes requisitos:

• Navegador compatible: Asegúrese de que el usuario utilice un navegador moderno que admita la Conditional UI (vea aquí la cobertura más reciente de los navegadores).
• JavaScript habilitado: JavaScript debe estar habilitado para facilitar las operaciones de la Conditional UI.
• Probar la disponibilidad de la Conditional UI: El relying party (lado del servidor) debe tener la certeza de que la Conditional UI está disponible en el lado del cliente cuando recibe la llamada de mediación WebAuthn para evitar desencadenar errores visibles para el usuario en escenarios donde no se admite la Conditional UI. Para abordar esto, se recomienda utilizar el método isConditionalMediationAvailable() y verificar la disponibilidad técnica de la Conditional UI (vea a continuación para más detalles).
• Campo de entrada HTML requerido: Para que funcione la Conditional UI, es necesario tener un campo de entrada HTML en su página web. Si no tiene uno, debe proporcionar soporte para el proceso regular de inicio de sesión con clave de acceso / WebAuthn que se activa con una interacción del usuario, como el clic en un botón.
• Eliminar protocolos de tiempo de espera: Los parámetros de tiempo de espera (por ejemplo, que el usuario tarde mucho en decidirse por una clave de acceso en el menú de autocompletado) deben ser ignorados en esta configuración.

Para que la Conditional UI funcione, también se deben cumplir algunos requisitos en el lado del servidor:

• Servidor WebAuthn en ejecución: Como todavía estamos en el contexto de las claves de acceso / WebAuthn, se requiere tener un servidor WebAuthn en ejecución que gestione los procedimientos de autenticación.
• Proporcionar endpoint de inicio de mediación: En comparación con los endpoints de inicio de sesión habituales de WebAuthn, es útil proporcionar otro endpoint que tenga una funcionalidad similar pero que pueda manejar un identificador de usuario opcional (por ejemplo, dirección de correo electrónico, número de teléfono, nombre de usuario).

Desde el lanzamiento oficial de la Conditional UI a fines de 2022 y versiones beta anteriores, hemos estado probando y trabajando extensamente con ella. A continuación, queremos compartir con usted consejos prácticos que ayudaron durante la implementación de la Conditional UI.

Experimenta con flujos de passkeys en Passkeys Debugger.

Probar gratis

Un ejemplo de código completo y minimalista para un método de Conditional UI se vería así:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // recuperar las opciones de solicitud (incl. el desafío) del servidor WebAuthn
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

Implemente una detección de Conditional UI que garantice que esta se emplee únicamente cuando la combinación actual de dispositivo / navegador lo admita. Esto debería funcionar sin presentar errores visibles para el usuario en ausencia de compatibilidad con la Conditional UI. La incorporación del método isConditionalMediationAvailable() dentro de la interfaz de usuario aborda esta preocupación. Si se da la compatibilidad, se puede iniciar el proceso de inicio de sesión de la Conditional UI.

// fuente: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// La disponibilidad de `window.PublicKeyCredential` significa que WebAuthn se puede utilizar.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Comprobar si la mediación condicional está disponible.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Llamar al endpoint de inicio de autenticación WebAuthn
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

El campo de entrada debe recibir un token de autocompletado HTML webauthn. Esto le indica al cliente que complete claves de acceso en la solicitud en curso. Además de las claves de acceso, también se pueden mostrar otros valores de autocompletado. Estos tokens de autocompletado se pueden combinar con otros tokens existentes, por ejemplo:

• autocomplete="username webauthn": Además de mostrar claves de acceso, esto también sugiere autocompletado de nombres de usuario.
• autocomplete="current-password webauthn": Además de mostrar claves de acceso, esto además solicita el autocompletado de contraseñas.

<label for="name">Nombre de usuario:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Contraseña:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Para obtener más detalles, recomendamos leer esta publicación del blog que proporciona más información sobre los tokens de autocompletado para claves de acceso y contraseñas.

Para recuperar las claves de acceso disponibles después de haber recibido el objeto PublicKeyCredentialRequestOptions, se debe llamar a la función navigator.credentials.get() (que sirve tanto para claves de acceso como para contraseñas). El objeto PublicKeyCredentialRequestOptions debe tener el parámetro mediation establecido en conditional para activar la Conditional UI en el cliente. Para los casos en los que desee un cuadro de diálogo modal de clave de acceso en su lugar, consulte la mediación inmediata.

const credential = await navigator.credentials.get({
    publicKey: options.publicKeyCredentialRequestOptions,
    mediation: "conditional",
});

Si no hay ninguna clave de acceso disponible, o el usuario ignora las claves de acceso sugeridas y entra su correo electrónico, el flujo de Conditional UI se detiene. Esto subraya la importancia de admitir siempre el inicio de sesión estándar de clave de acceso / WebAuthn a través de un modal también.

Un punto crítico a destacar aquí es la posible necesidad de detener una solicitud de Conditional UI en curso. Al contrario de las experiencias modales, los menús desplegables de autocompletado carecen de un botón de cancelación. Según el diseño de WebAuthn, solo una solicitud de credencial activa única debería estar en curso en un momento dado. El estándar de WebAuthn sugiere utilizar un AbortController para cancelar un proceso de WebAuthn, aplicable tanto a los procesos de inicio de sesión regulares como a los de Conditional UI (ver aquí para obtener detalles).

En la telemetría de producción, esta ruta de cancelación suele ser un resultado esperado del flujo de control, no una falla del sistema. Si observa altos volúmenes de errores, debe clasificar los casos esperados frente a los inesperados por tipo de operación y tiempo antes de tratarlos como regresiones (consulte Errores de WebAuthn).

El proceso de inicio de sesión de Conditional UI se activa tan pronto como un usuario llega a la página. La tarea inicial debe ser crear un objeto AbortController de alcance global. Esto actuará como una señal para que su cliente termine la solicitud de autocompletado, especialmente si el usuario decide realizar el proceso de inicio de sesión habitual de claves de acceso. Asegúrese de que el AbortController pueda ser invocado por otras funciones y que se restablezca si el proceso de Conditional UI tiene que reiniciarse. Emplee la propiedad signal dentro de la llamada navigator.credentials.get(), incorporando la señal de su AbortController como valor. Esto señala a la función de clave de acceso / WebAuthn que la solicitud debe detenerse si la señal es abortada. Recuerde configurar un nuevo AbortController cada vez que active la Conditional UI. El uso de un AbortController ya abortado provocará la cancelación instantánea de la función de clave de acceso / WebAuthn. Los pasos restantes se alinean con un proceso de inicio de sesión de clave de acceso regular. A continuación, puede ver un ejemplo de código de los pasos mencionados:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Conditional UI</title>
    </head>
    <body>
        <input type="text" id="username" autocomplete="username webauthn" />
 
        <script>
            async function passkeyLogin() {
                try {
                    // recuperar las opciones de solicitud (incl. el desafío) del servidor WebAuthn
                    let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
                    const credential = await navigator.credentials.get({
                        publicKey: options.publicKeyCredentialRequestOptions,
                        mediation: "conditional",
                    });
 
                    const userData = await WebAuthnClient.sendSignedChallenge(credential);
                    window.location.href = "/logged-in";
                } catch (error) {
                    console.log(error);
                }
            }
 
            passkeyLogin();
        </script>
    </body>
</html>

En ausencia de soporte para Conditional UI, dirija a los usuarios hacia el proceso de inicio de sesión regular con clave de acceso. Ofrecer esta ruta es importante para los usuarios que dependen de llaves de seguridad de hardware (por ejemplo, YubiKeys) o para aquellos obligados a utilizar claves no residentes / credenciales no descubribles debido a las restricciones del autenticador.

Consulta cuántas personas usan passkeys realmente.

Ver datos de adopción

Cuando desarrolla una aplicación nativa, por ejemplo, para iOS o Android, la Conditional UI también funciona. No importa si la implementa de forma nativa en Flutter, Kotlin o Swift, o si decide optar por Chrome Custom Tabs CCT o SFSafariViewController o SFAuthenticationSession / ASWebAuthenticationSession. Ambos enfoques son compatibles con la Conditional UI.

En general, no encontramos casi ninguna documentación sobre cómo implementar la compatibilidad con Conditional UI para las aplicaciones de iOS. Durante nuestra investigación, sin embargo, descubrimos dos formas de agregar la compatibilidad con Conditional UI a una aplicación de iOS, ya que la experiencia del usuario también será diferente.

Tipo A: Superposición / Ventana emergente en casi toda la pantalla

El primer tipo A muestra una superposición / ventana emergente que abarca casi toda la pantalla. Aquí, verá todas las claves de acceso disponibles para este relying party. Un ejemplo destacado que implementa la Conditional UI de esta manera es KAYAK. La superposición / ventana emergente surge automáticamente cuando el usuario abre la pantalla correcta.

Tipo B: Autocompletado de teclado

El segundo tipo B muestra una clave de acceso adecuada en la sección de autocompletado del teclado (donde también se sugieren contraseñas para autocompletar). Al hacer clic en el valor sugerido, se realizará la autenticación con Face ID y le permitirá iniciar sesión. En la versión actual de la aplicación de iOS del panel de desarrollador de Corbado, la hemos implementado de esta manera (ver el mensaje Iniciar sesión con clave de acceso para <relying party ID> junto con el nombre de usuario de WebAuthn). Para que aparezca, el usuario debe tocar el campo de entrada:

Esta función de autocompletado de clave de acceso en la sección del teclado puede tener problemas cuando iOS está recién instalado, ya que aparentemente ocurre algún tipo de caché en segundo plano que busca todas las claves de acceso disponibles para este relying party.

Al hacer clic en el icono de la llave a la derecha de la clave de acceso sugerida, se accede al sitio conocido para elegir contraseñas / claves de acceso en iOS:

Tenga en cuenta que no hemos encontrado documentación oficial, y nuestros conocimientos se basan en nuestras experiencias e hipótesis en lugar de pruebas concretas de la implementación adecuada.

En Android, la historia de la Conditional UI es un poco más clara, ya que solo hay un tipo de Conditional UI / autocompletado de claves de acceso que aprovecha la API Credential Manager de Android (consulte la documentación aquí). Debido a que los proveedores de Android pueden diferir, supervise los errores de claves de acceso de Credential Manager por separado de los patrones de falla de WebAuthn de solo navegador.

Al abrir la página donde se implementa la Conditional UI, se muestra la siguiente pantalla, donde encontrará diferentes formas de iniciar sesión:

Al hacer clic en Más inicios de sesión guardados, se proporcionan más opciones a elegir para el inicio de sesión (incluida la autenticación entre dispositivos y la selección de una plataforma de sincronización de claves de acceso diferente, por ejemplo, Samsung Pass o 1Password):

Para ilustrar cómo se ve la Conditional UI para el usuario final, agregamos varias capturas de pantalla de un menú de autocompletado de Conditional UI utilizando https://passkeys.eu.

Prueba passkeys en una demo en vivo.

Probar passkeys

Echemos un vistazo a algunos escenarios comunes en aplicaciones de la vida real.

Si no hay ninguna clave de acceso guardada para un sitio, la Conditional UI se comportará de manera diferente según el navegador y el sistema operativo.

En Chrome en macOS, al hacer clic en el campo de entrada se muestra un menú desplegable de autocompletado vacío:

En Safari en macOS, no se muestra ningún menú desplegable, solo un icono sutil en el campo de entrada:

En Android o iOS, la interfaz de autocompletado aparece solo si el usuario toca el campo y el sistema operativo encuentra credenciales coincidentes.

Esta variabilidad es intencional y parte del modelo de privacidad de WebAuthn: los sitios web no pueden detectar si el usuario tiene una clave de acceso a menos que este seleccione una activamente.

Si un usuario tiene varios proveedores de claves de acceso instalados (por ejemplo, iCloud Keychain, Google Password Manager, 1Password), el navegador o el sistema operativo suele seleccionar por defecto el gestor de credenciales principal del usuario.

Para obtener una lista de diferentes proveedores de claves de acceso / gestores de credenciales que admiten claves de acceso, le recomendamos echar un vistazo al siguiente enlace de GitHub.

En Android, Credential Manager expone a diferentes proveedores como Samsung Pass o 1Password.

1. Al hacer clic en el campo de entrada del identificador de usuario, aparece este menú donde el usuario puede seleccionar una clave de acceso.

2. Si el usuario hizo clic en "Más claves de acceso" en la pantalla anterior, aparece una preselección de otros proveedores de claves de acceso / gestores de credenciales y claves de acceso:

3. Si el usuario hizo clic en "Más inicios de sesión guardados" en la pantalla anterior, aparece una lista completa donde el usuario puede seleccionar una clave de acceso.

En iOS, el icono de la llave abre la lista completa de claves de acceso de diversas fuentes.

1. Al principio, en iOS 18+, aparece la Conditional UI habitual con el proveedor de claves de acceso predeterminado.

2. Al hacer clic en el icono del teclado, aparece el siguiente menú de selección.

3. Después de seleccionar un gestor de credenciales / proveedor de claves de acceso, el usuario puede seleccionar la clave de acceso a utilizar.

Las claves de acceso, con su capacidad de Conditional UI / autocompletado de claves de acceso, son la nueva forma de autenticarse en línea. A medida que hacemos la transición a una era en la que las contraseñas son reemplazadas cada vez más por las claves de acceso, la necesidad de mecanismos de transición robustos y fáciles de usar es innegable. Este artículo ha ayudado a comprender cómo implementar correctamente la Conditional UI, una gran ayuda en el proceso de transición, y a qué aspectos se les debe prestar especial atención.

Acerca de Corbado

Corbado es la Authentication 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 →

Llame a PublicKeyCredential.isConditionalMediationAvailable() y proceda solo si devuelve un valor verdadero. Esta comprobación evita errores visibles para el usuario en combinaciones de navegadores y dispositivos no compatibles. El método debe evaluarse en cada carga de página antes de llamar a navigator.credentials.get() con mediation: "conditional".

Los autenticadores solo almacenan datos específicos del usuario, como el nombre y el nombre para mostrar, en las claves residentes (credenciales descubribles). Las claves no residentes no conservan esta información, por lo que el menú de autocompletado no puede cargar los detalles de la cuenta para que el usuario los seleccione.

El comportamiento varía según la plataforma. Chrome en macOS muestra un menú desplegable de autocompletado vacío, Safari en macOS solo muestra un icono sutil en el campo de entrada y, en Android o iOS, la interfaz de autocompletado solo aparece si el sistema operativo encuentra credenciales coincidentes después de que el usuario toca el campo. Esta variabilidad es intencional y forma parte del modelo de privacidad de WebAuthn: los sitios web no pueden detectar si existe una clave de acceso a menos que el usuario seleccione una activamente.

Cree un AbortController de alcance global y pase su señal a navigator.credentials.get(). Llame a .abort() en el controlador cuando el usuario inicie un flujo de inicio de sesión modal. Cree siempre un nuevo AbortController cada vez que se reinicie la Conditional UI, ya que la reutilización de un controlador ya abortado provoca la cancelación inmediata de la solicitud de WebAuthn.

La Conditional UI funciona tanto en aplicaciones nativas de iOS como de Android. iOS admite dos variantes: una ventana emergente superpuesta a pantalla completa y una sugerencia de autocompletado de teclado. Android utiliza la API Credential Manager, que puede mostrar claves de acceso de varios proveedores, como Samsung Pass o 1Password.