Explicação técnica da UI condicional do WebAuthn (Preenchimento automático de chaves de acesso)

Cheatsheet de Passkeys. Guias práticos, padrões de implementação e KPIs para programas de passkeys.

Obter cheat sheet

Com a rápida adoção das chaves de acesso (e do protocolo WebAuthn subjacente), a autenticação tornou-se mais segura e fácil de usar para muitos usuários. Um dos avanços de destaque das chaves de acesso tem sido a integração da UI condicional, muitas vezes referida como "preenchimento automático de chaves de acesso" ou Conditional Mediation (a seguir, manteremos o termo UI condicional).

Apesar de sua introdução recente e adoção contínua pelos navegadores, há uma lacuna notável na documentação técnica e conselhos de implementação para a UI condicional. Este artigo tem como objetivo preencher essa lacuna explicando o que é a UI condicional, como ela funciona e como enfrentar os desafios comuns durante sua implementação.

A UI condicional representa um novo modo para os processos de login com chaves de acesso / WebAuthn. Ela exibe seletivamente as chaves de acesso em uma interface de usuário (UI) apenas quando um usuário tem uma credencial descobrível (chave residente), que é um tipo de chave de acesso registrada com a parte confiável (o serviço online) e armazenada em seu autenticador de um dispositivo (por exemplo, laptop, smartphone). As chaves de acesso são exibidas em um menu suspenso de seleção misturado com senhas preenchidas automaticamente, proporcionando uma transição perfeita entre os sistemas de senhas tradicionais e a autenticação avançada por chaves de acesso, já que os usuários veem ambos no mesmo contexto. Esta abordagem inteligente garante que os usuários não fiquem sobrecarregados com opções desnecessárias e possam navegar no processo de login de forma mais 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

A base da UI condicional é construída sobre três pilares principais:

1. Respeito à privacidade do usuário: Garantir a privacidade do usuário, evitando a divulgação de credenciais disponíveis ou a falta de consentimento do usuário para revelar essas credenciais.
2. Ótima experiência do usuário mesmo se não houver chave de acesso: Capacitar as partes confiáveis a implementar o WebAuthn de forma oportunista, garantindo que a experiência do usuário permaneça boa mesmo que as chaves de acesso não estejam disponíveis.
3. Transição suave de senhas para chaves de acesso: Combinar chaves de acesso com autenticação baseada em senha para suavizar a transição em direção a métodos de autenticação sem senha, capitalizando sobre os paradigmas de UX familiares dos usuários.

• Autenticação simplificada: O processo é mais simplificado e eficiente, removendo as complexidades frequentemente associadas a vários métodos de autenticação.
• Redução de erros do usuário: Ao apresentar apenas as opções relevantes, é menos provável que os usuários cometam erros durante o processo de autenticação.
• Maior satisfação do usuário: Remover etapas desnecessárias significa que os usuários podem fazer login de forma mais rápida e sem esforço, levando a uma melhor satisfação do usuário.
• Integração simples no frontend: Uma das características de destaque da UI condicional é a sua facilidade de integração. Os desenvolvedores podem incorporá-la perfeitamente no frontend com algumas linhas de código (veja abaixo).
• Login sem senha e sem nome de usuário: Um dos grandes benefícios é que a UI condicional promove não apenas a autenticação sem senha, mas também uma experiência sem nome de usuário ou sem conta. Os usuários são poupados da carga mental de lembrar seu endereço de e-mail específico ou identificador de usuário do momento do cadastro. Em vez disso, eles podem confiar nas sugestões dos navegadores, que incluem o endereço de e-mail/identificador de usuário emparelhado com a chave de acesso apropriada no menu de preenchimento automático.
• Resolvendo o dilema de inicialização: A transição de sistemas tradicionais de nome de usuário e senha para chaves de acesso pode ser assustadora. A UI condicional aborda esse desafio de transição. Os sites podem iniciar uma chamada de chave de acesso / WebAuthn juntamente com um prompt de senha convencional sem se preocupar com possíveis erros de caixa de diálogo modal se um dispositivo não tiver as credenciais necessárias.

Assine nosso Substack de passkeys para receber as últimas novidades.

Assinar

• Curva de aprendizado para desenvolvedores: A UI condicional introduz um novo paradigma, o que significa que há uma curva de aprendizado envolvida para os desenvolvedores não familiarizados com suas complexidades.
• Dependência de dispositivo / navegador: O sucesso das UIs condicionais depende da compatibilidade do dispositivo ou navegador do usuário. Dado que nem todos os navegadores ou dispositivos a suportam atualmente, isso pode limitar sua aplicação.
• Gerenciadores de senhas desativam o preenchimento automático: Alguns gerenciadores de senhas modernos e suas extensões de navegador modificam o DOM do site e desativam ou sobrescrevem a tag autocomplete em campos de entrada em favor de seus próprios recursos de preenchimento automático. Isso pode levar a uma experiência de usuário inconsistente e insatisfatória. Como os padrões para a UI condicional são relativamente novos, esperamos que as coisas melhorem, de modo que, por exemplo, não haja sobreposição de dois menus de preenchimento automático ou que o menu desejado não seja ocultado.

A seguir, fornecemos um detalhamento passo a passo das etapas individuais de um fluxo completo de UI condicional:

Em geral, o fluxo do processo da UI condicional pode ser particionado em duas fases. Durante a fase de carregamento da página, a lógica da UI condicional acontece em segundo plano, enquanto na fase de operação do usuário, o usuário deve fazer algo ativamente.

1. Verificação de disponibilidade da UI condicional: O cliente (navegador) chama a função isConditionalMediationAvailable() para detectar se a combinação atual de navegador / dispositivo suporta a UI condicional. Apenas se a resposta for verdadeira, o processo continua, caso contrário, o processo de UI condicional é abortado.
2. Chamar o endpoint da UI condicional: Em seguida, o cliente chama o endpoint da UI condicional do servidor para recuperar as PublicKeyCredentialRequestOptions.
3. Receber PublicKeyCredentialRequestOptions: O servidor retorna as PublicKeyCredentialRequestOptions que contêm o desafio e mais opções do servidor WebAuthn (por exemplo, allowCredentials, extensões, userVerification).
4. Iniciar a autenticação local: Ao chamar credentials.get() com as PublicKeyCredentialRequestOptions recebidas e a propriedade mediation configurada para ser condicional, o processo para a autenticação local no dispositivo é iniciado.
5. Mostrar seleção de preenchimento automático: O menu de preenchimento automático para chaves de acesso é exibido. O estilo específico depende do navegador e do dispositivo (por exemplo, alguns exigem que o usuário coloque o cursor no campo de entrada, alguns exibem automaticamente o menu no carregamento da página, veja abaixo).
6. Autenticação de usuário local: O usuário seleciona a chave de acesso no menu de preenchimento automático que deseja usar e se autentica na caixa de diálogo de autenticação do seu dispositivo (por exemplo, via Face ID, Touch ID, Windows Hello).
7. Enviar resposta do autenticador ao servidor: Se a autenticação de usuário local for bem-sucedida, a resposta do autenticador é enviada de volta ao servidor.
8. O usuário está conectado e é redirecionado: Assim que o servidor recebe a resposta do autenticador, ele valida a assinatura contra a chave pública da conta de usuário correspondente no banco de dados. Se a verificação for bem-sucedida, o acesso é concedido ao usuário, que faz login e é redirecionado para a página autenticada.

Ao seguir esse fluxo de processo, a UI condicional oferece uma experiência de autenticação perfeita e fácil de usar.

Para que a UI condicional funcione, alguns aspectos gerais precisam ser considerados:

• Especificações de credenciais: A UI condicional é especificamente projetada para operar apenas com chaves residentes / credenciais descobríveis. O motivo por trás disso é que os autenticadores não armazenam dados específicos do usuário (por exemplo, nome, nome de exibição) para chaves não residentes / credenciais não descobríveis. Como resultado, o uso destas últimas para o preenchimento automático de chaves de acesso não é possível.
• Filtragem de credenciais: O recurso allowCredentials continua sendo suportado, facilitando os sites que já estão cientes da identidade do usuário (por exemplo, se um nome de usuário foi enviado na chamada de mediação inicial porque pode estar armazenado no LocalStorage dos navegadores) para refinar a lista de credenciais exibidas aos usuários durante o preenchimento automático.

Participe da nossa comunidade de passkeys para atualizações e suporte.

Entrar

Para que a UI condicional funcione no lado do cliente, os seguintes requisitos devem ser cumpridos:

• Navegador compatível: Certifique-se de que o usuário use um navegador moderno que suporte a UI condicional (veja aqui para a cobertura de navegadores mais recente).
• JavaScript habilitado: O JavaScript deve estar habilitado para facilitar as operações de UI condicional.
• Testar disponibilidade da UI condicional: A parte confiável (lado do servidor) deve ter a certeza de que a UI condicional está disponível no lado do cliente, quando recebe a chamada de mediação WebAuthn, para evitar acionar quaisquer erros visíveis ao usuário em cenários onde a UI condicional não é suportada. Para resolver isso, é recomendável usar o método isConditionalMediationAvailable() e verificar a disponibilidade técnica da UI condicional (veja abaixo para mais detalhes).
• Campo de entrada HTML necessário: Para que a UI condicional funcione, você precisa ter um campo de entrada HTML em sua página da web. Se você não tiver um, precisará fornecer suporte para o processo normal de login por chave de acesso / WebAuthn que é acionado por uma interação do usuário, como um clique de botão.
• Remover protocolos de tempo limite: Parâmetros de tempo limite (por exemplo, o usuário está demorando muito para se decidir por uma chave de acesso no menu de preenchimento automático) devem ser desconsiderados nesta configuração.

Para que a UI condicional funcione, alguns requisitos no lado do servidor também devem ser cumpridos:

• Servidor WebAuthn em execução: Como ainda estamos no contexto de chaves de acesso / WebAuthn, é necessário ter um servidor WebAuthn em execução que gerencie os procedimentos de autenticação.
• Fornecer endpoint de início da mediação: Em comparação com os endpoints normais de login WebAuthn, é útil fornecer outro endpoint que tenha funcionalidade semelhante, mas que possa lidar com um identificador de usuário opcional (por exemplo, endereço de e-mail, número de telefone, nome de usuário).

Desde o lançamento oficial da UI condicional no final de 2022 e as versões beta anteriores, temos testado e trabalhado extensivamente com ela. A seguir, queremos compartilhar com você dicas práticas que ajudaram durante a implementação da UI condicional.

Experimente fluxos de passkeys no Passkeys Debugger.

Testar grátis

Um exemplo de código completo e minimalista para um método de UI condicional seria assim:

<!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 {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    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 a detecção da UI condicional que garante que a UI condicional seja empregada apenas quando a combinação de dispositivo / navegador atual a suportar. Isso deve funcionar sem apresentar erros visíveis ao usuário na ausência de suporte à UI condicional. Incorporar o método isConditionalMediationAvailable() dentro da interface de usuário resolve essa preocupação. Se houver suporte à UI condicional, o processo de login da UI condicional pode ser iniciado.

// source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples
 
// Availability of `window.PublicKeyCredential` means WebAuthn is usable.
if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) {
    // Check if conditional mediation is available.
    const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();
    if (isCMA) {
        // Call WebAuthn authentication start endpoint
 
        let options = await WebAuthnClient.getPublicKeyRequestOptions();
 
        const credential = await navigator.credentials.get({
            publicKey: options.publicKeyCredentialRequestOptions,
            mediation: "conditional",
        });
        /*
        ...
        */
    }
}

O campo de entrada deve receber um token de preenchimento automático HTML webauthn. Isso sinaliza ao cliente para preencher as chaves de acesso na solicitação em andamento. Além de chaves de acesso, outros valores de preenchimento automático também podem ser exibidos. Esses tokens de preenchimento automático podem ser emparelhados com outros tokens existentes, por exemplo:

• autocomplete="username webauthn": Além de exibir chaves de acesso, isso também sugere o preenchimento automático do nome de usuário.
• autocomplete="current-password webauthn": Além de exibir chaves de acesso, isso também solicita o preenchimento automático de senha.

<label for="name">Username:</label>
<input type="text" name="name" autocomplete="username webauthn" />
<label for="password">Password:</label>
<input type="password" name="password" autocomplete="current-password webauthn" />

Para mais detalhes, recomendamos ler esta postagem de blog que fornece mais detalhes sobre tokens de preenchimento automático para chaves de acesso e senhas.

Para recuperar as chaves de acesso disponíveis depois de ter recebido o objeto PublicKeyCredentialRequestOptions, a função navigator.credentials.get() deve ser chamada (que serve para chaves de acesso e senhas). O objeto PublicKeyCredentialRequestOptions precisa ter o parâmetro mediation configurado como condicional para ativar a UI condicional no cliente. Para casos onde você deseja um prompt de chave de acesso modal em vez disso, veja mediação imediata.

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

Se não houver chave de acesso disponível, ou se o usuário negligenciar as chaves de acesso sugeridas e inserir seu e-mail, o fluxo da UI condicional é interrompido. Isso ressalta a importância de sempre suportar o login padrão por chave de acesso / WebAuthn através de um modal também.

Um ponto crítico a ser enfatizado aqui é a necessidade potencial de interromper uma solicitação de UI condicional em andamento. Ao contrário das experiências modais, os menus suspensos de preenchimento automático não possuem um botão de cancelamento. De acordo com o design do WebAuthn, apenas uma única solicitação de credencial ativa deve estar em andamento a qualquer momento. O padrão WebAuthn sugere utilizar um AbortController para cancelar um processo WebAuthn, aplicável a processos normais de login ou de UI condicional (veja aqui para detalhes).

Na telemetria de produção, esse caminho de cancelamento geralmente é um resultado de fluxo de controle esperado, não uma falha de sistema. Se você observar grandes volumes de erros, você precisa classificar os casos esperados e inesperados por tipo de operação e tempo antes de tratá-los como regressões (veja erros WebAuthn).

O processo de login da UI condicional é ativado assim que um usuário chega à página. A tarefa inicial deve ser criar um objeto AbortController de escopo global. Isso atuará como um sinal para seu cliente terminar a solicitação de preenchimento automático, especialmente se o usuário decidir fazer o processo normal de login por chave de acesso. Certifique-se de que o AbortController possa ser invocado por outras funções e seja reinicializado se o processo da UI condicional tiver que ser reiniciado. Empregue a propriedade signal dentro da chamada navigator.credentials.get(), incorporando seu sinal AbortController como seu valor. Isso sinaliza para a função da chave de acesso / WebAuthn que a solicitação deve ser interrompida se o sinal for abortado. Lembre-se de configurar um novo AbortController a cada vez que você acionar a UI condicional. O uso de um AbortController já abortado levará a um cancelamento instantâneo da função chave de acesso / WebAuthn. As etapas restantes se alinham com um processo de login normal de chave de acesso. A seguir, você vê um exemplo de código das etapas mencionadas:

<!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 {
                    // retrieve the request options (incl. the challenge) from the WebAuthn server
                    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>

Na ausência de suporte à UI condicional, direcione os usuários para o processo normal de login por chave de acesso. Oferecer este caminho é importante para os usuários que dependem de chaves de segurança de hardware (por exemplo, YubiKeys) ou para aqueles obrigados a usar chaves não residentes / credenciais não descobríveis devido a restrições do autenticador.

Veja quantas pessoas realmente usam passkeys.

Ver dados de adoção

Quando você desenvolve um aplicativo nativo, por exemplo, para iOS ou Android, a UI condicional também funciona. Não importa se você a implementa nativamente no Flutter, Kotlin ou Swift, ou se você decide usar as Chrome Custom Tabs CCT ou SFSafariViewController ou SFAuthenticationSession / ASWebAuthenticationSession. Ambas as abordagens suportam a UI condicional.

Em geral, quase não encontramos documentação sobre como implementar o suporte à UI condicional para aplicativos iOS. Durante nossa pesquisa, no entanto, descobrimos duas formas de adicionar suporte à UI condicional em um aplicativo iOS, já que a experiência do usuário também vai diferir.

Tipo A: Sobreposição / Popup sobre quase toda a tela

O primeiro tipo A mostra uma sobreposição / popup que abrange quase toda a tela. Aqui, você verá todas as chaves de acesso disponíveis para esta parte confiável. Um exemplo proeminente que implementa a UI condicional dessa forma é o KAYAK. A sobreposição / popup surge automaticamente quando o usuário abre a tela correta.

Tipo B: Preenchimento automático do teclado

O segundo tipo B exibe uma chave de acesso adequada na seção de preenchimento automático do teclado (onde as senhas também são sugeridas para preenchimento automático). Clicar no valor sugerido realizará a autenticação Face ID e permitirá que você faça o login. Na versão atual do aplicativo iOS do painel de desenvolvedor Corbado, implementamos dessa forma (veja a mensagem "Sign in with passkey for <relying party ID>" junto com o nome de usuário WebAuthn). Para aparecer, o usuário precisa tocar no campo de entrada:

Este recurso de preenchimento automático de chaves de acesso na seção do teclado pode ter problemas quando o iOS é recém-instalado, pois aparentemente algum tipo de cache ocorre em segundo plano para procurar todas as chaves de acesso disponíveis para esta parte confiável.

Clicar no ícone de chave à direita da chave de acesso sugerida leva ao site conhecido para escolher senhas / chaves de acesso no iOS:

Observe que não encontramos documentação oficial, e nossas constatações são baseadas em nossas experiências e hipóteses em vez de uma prova concreta da implementação adequada.

No Android, a história da UI condicional é um pouco mais clara, pois há apenas um tipo para UI condicional / preenchimento automático de chaves de acesso que aproveita a API Android Credential Manager (veja a documentação aqui). Como os provedores no Android podem diferir, monitore os erros de chaves de acesso do Credential Manager separadamente dos padrões de falha WebAuthn exclusivas de navegadores.

Abrir a página onde a UI condicional é implementada mostra a tela seguinte, onde você encontrará diferentes maneiras de fazer o login:

Clicar em Mais logins salvos fornece mais opções para escolher para o login (incluindo autenticação entre dispositivos e a seleção de uma plataforma diferente de sincronização de chaves de acesso, por exemplo, Samsung Pass ou 1Password):

Para ilustrar como a UI condicional se parece para o usuário final, adicionamos várias capturas de tela de um menu de preenchimento automático de UI condicional usando https://passkeys.eu.

Teste passkeys em uma demo ao vivo.

Testar passkeys

Vamos dar uma olhada em alguns cenários comuns em aplicações do mundo real.

Se não houver chave de acesso salva para um site, a UI condicional se comportará de maneira diferente, dependendo do navegador e do SO.

No Chrome no macOS, clicar no campo de entrada mostra um menu suspenso de preenchimento automático vazio:

No Safari no macOS, nenhum menu suspenso é mostrado - apenas um ícone sutil no campo de entrada:

No Android ou iOS, a interface de preenchimento automático aparece apenas se o usuário tocar no campo e o SO encontrar credenciais correspondentes.

Essa variabilidade é intencional e faz parte do modelo de privacidade do WebAuthn: os sites não podem detectar se o usuário tem uma chave de acesso, a menos que o usuário ativamente a selecione.

Se um usuário tiver instalados múltiplos provedores de chaves de acesso (por exemplo, iCloud Keychain, Google Password Manager, 1Password), o navegador ou o SO geralmente adotará como padrão o gerenciador de credenciais principal do usuário.

Para obter uma lista de diferentes provedores de chaves de acesso / gerenciadores de credenciais que suportam chaves de acesso, recomendamos conferir o seguinte link do GitHub.

No Android, a Credential Manager expõe provedores diferentes como Samsung Pass ou 1Password.

1. Ao clicar no campo de entrada de identificação do usuário, esse menu surge e o usuário pode selecionar uma chave de acesso.

2. Se o usuário clicou em "Mais chaves de acesso" na tela anterior, uma pré-seleção de outros provedores de chaves de acesso / gerenciadores de credenciais e chaves de acesso aparecerá:

3. Se o usuário clicou em "Mais logins salvos" na tela anterior, uma lista inteira de opções disponíveis surge para o usuário selecionar uma chave de acesso.

No iOS, o ícone da chave abre a lista completa de chaves de acesso de várias fontes.

1. A princípio, no iOS 18+, a UI condicional normal com o provedor de chaves de acesso padrão aparece.

2. Ao clicar no ícone do teclado, o menu de seleção seguinte aparece.

3. Depois de selecionar um gerenciador de credenciais / provedor de chaves de acesso, o usuário pode selecionar a chave de acesso a ser usada.

As chaves de acesso (passkeys), com a sua capacidade de UI condicional / preenchimento automático de chaves de acesso, são a nova maneira de autenticar-se online. Conforme transitamos para uma era em que as senhas estão sendo cada vez mais substituídas por chaves de acesso, a necessidade de mecanismos de transição robustos e amigáveis é inegável. Este artigo ajudou a compreender como implementar corretamente a UI condicional, uma grande ajuda no processo de transição, e a quais aspectos prestar atenção especial.

Sobre a Corbado

Corbado é a Authentication Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

Chame PublicKeyCredential.isConditionalMediationAvailable() e continue apenas se ele retornar "true". Esta verificação evita erros visíveis ao usuário em combinações de dispositivos e navegadores que não têm suporte a isso. O método deve ser avaliado em cada carregamento da página antes de chamar navigator.credentials.get() com mediation: "conditional".

Os autenticadores armazenam apenas dados específicos do usuário, como o nome e o nome de exibição para chaves residentes (credenciais descobríveis). Chaves não residentes não retêm essas informações, portanto, o menu de preenchimento automático não pode preencher os detalhes da conta para o usuário selecionar.

O comportamento varia por plataforma. O Chrome no macOS mostra um menu suspenso de preenchimento automático vazio, o Safari no macOS mostra apenas um ícone sutil no campo de entrada e, no Android ou iOS, a interface de preenchimento automático aparece apenas se o SO encontrar credenciais correspondentes depois que o usuário tocar no campo. Esta variabilidade é intencional e faz parte do modelo de privacidade do WebAuthn: sites não conseguem detectar se existe uma chave de acesso, a menos que o usuário selecione uma de forma ativa.

Crie um AbortController de escopo global e passe seu "signal" para navigator.credentials.get(). Chame .abort() no controlador quando o usuário iniciar um fluxo de login modal. Instancie sempre um novo AbortController a cada vez que a UI condicional reiniciar, pois reutilizar um controlador que já foi abortado causa o cancelamento imediato da solicitação WebAuthn.

A UI condicional funciona em aplicativos nativos de iOS e Android. O iOS tem suporte a duas variantes: um pop-up de sobreposição em tela cheia e uma sugestão de preenchimento automático de teclado. O Android usa a API Credential Manager, que pode exibir chaves de acesso de múltiplos provedores, como Samsung Pass ou 1Password.