A API Web Authentication, também conhecida como WebAuthn, permite que os servidores usem criptografia de chave pública em vez de senhas para registrar e autenticar usuários. Para isso, ele ativa a integração entre esses servidores e autenticadores fortes. Esses autenticadores podem ser dispositivos físicos dedicados (por exemplo, chaves de segurança) ou integrados a plataformas (por exemplo, leitores de impressão digital). Saiba mais sobre o WebAuthn em webauthn.guide.
Dificuldades dos desenvolvedores
Antes desse projeto, o WebAuthn não tinha suporte nativo de depuração no Chrome. Um desenvolvedor que cria um app que usa a WebAuth precisa de acesso a autenticadores físicos. Isso foi especialmente difícil por dois motivos:
Há muitos tipos diferentes de autenticadores. A depuração da amplitude das configurações e recursos exigia que o desenvolvedor tivesse acesso a muitos autenticadores diferentes, às vezes caros.
Os autenticadores físicos são seguros por design. Portanto, a inspeção do estado deles geralmente é impossível.
Para facilitar isso, adicionamos suporte à depuração diretamente no Chrome DevTools.
Solução: uma nova guia do WebAuthn
A guia "WebAuthn DevTools" facilita a depuração da WebAuthn, permitindo que os desenvolvedores emulem esses autenticadores, personalizem os recursos e inspecionem os estados.
Implementação
Adicionar suporte à depuração ao WebAuthn foi um processo de duas partes.
Parte 1: adicionar o domínio WebAuthn ao protocolo das Ferramentas do desenvolvedor do Chrome
Primeiro, implementamos um novo domínio no Chrome DevTools Protocol (CDP), que se conecta a um gerenciador que se comunica com o back-end do WebAuthn.
O CDP conecta o front-end do DevTools ao Chromium. No nosso caso, usamos as ações do domínio WebAuthn para fazer a ponte entre a guia do WebAuthn DevTools e a implementação do WebAuthn do Chromium.
O domínio do WebAuthn permite ativar e desativar o ambiente do autenticador virtual, que desconecta o navegador da descoberta real do autenticador e conecta uma descoberta virtual.
Também expomos métodos no domínio que funcionam como uma camada fina para as interfaces do autenticador virtual e do discovery virtual, que fazem parte da implementação do WebAuthn do Chromium. Esses métodos incluem adição e remoção de autenticadores, além de criação, recebimento e exclusão de credenciais registradas.
(Leia o código.)
Parte 2: criar a guia voltada ao usuário
Em segundo lugar, criamos uma guia voltada ao usuário no front-end das Ferramentas do desenvolvedor. A guia é composta por uma visualização e um modelo. Um agente gerado automaticamente conecta o domínio à guia.
Embora haja três componentes necessários, só precisamos nos preocupar com dois deles: o modelo e a visualização. O terceiro componente, o agente, é gerado automaticamente após a adição do domínio. Resumidamente, o agente é a camada que processa as chamadas entre o front-end e o CDP.
O modelo
O modelo é a camada JavaScript que conecta o agente e a visualização. No nosso caso, o modelo é bastante simples. Ele recebe comandos da visualização, cria as solicitações para que sejam consumidas pelo CDP e as envia pelo agente. Essas solicitações geralmente são unidirecionais, sem informações enviadas de volta para a visualização.
No entanto, às vezes, transmitimos uma resposta do modelo para fornecer um ID de um autenticador recém-criado ou para retornar as credenciais armazenadas em um autenticador existente.
(Leia o código.)
A visualização
Usamos a visualização para fornecer a interface do usuário que um desenvolvedor pode encontrar ao acessar as Ferramentas do desenvolvedor. Ele contém:
- Uma barra de ferramentas para ativar o ambiente do autenticador virtual.
- Uma seção para adicionar autenticadores.
- Uma seção para autenticadores criados.
(Leia o código.)
Barra de ferramentas para ativar o ambiente do autenticador virtual
Como a maioria das interações do usuário é com um autenticador por vez, e não com a guia inteira, a única funcionalidade que oferecemos na barra de ferramentas é ativar e desativar o ambiente virtual.
Por que isso é necessário? É importante que o usuário alterne explicitamente o ambiente, porque isso desconecta o navegador da descoberta real do autenticador. Portanto, enquanto ele estiver ativado, os autenticadores físicos conectados, como um leitor de impressão digital, não serão reconhecidos.
Decidimos que um botão de alternância explícito significa uma experiência do usuário melhor, especialmente para aqueles que acessam a guia "WebAuthn" sem esperar que a descoberta real seja desativada.
Como adicionar a seção "Autenticadores"
Ao ativar o ambiente do autenticador virtual, apresentamos ao desenvolvedor um formulário inline que permite adicionar um autenticador virtual. Nesse formulário, oferecemos opções de personalização que permitem ao usuário decidir os métodos de protocolo e transporte do autenticador, bem como se o autenticador oferece suporte a chaves residentes e à verificação do usuário.
Quando o usuário clica em Adicionar, essas opções são agrupadas e enviadas ao modelo que faz a chamada para criar um autenticador. Depois disso, o front-end vai receber uma resposta e modificar a interface para incluir o autenticador recém-criado.
Visualização do Authenticator
Sempre que um autenticador é emulado, adicionamos uma seção à visualização do autenticador para representá-lo. Cada seção de autenticador inclui um nome, um ID, opções de configuração, botões para remover o autenticador ou ativar e uma tabela de credenciais.
O nome do Authenticator
O nome do autenticador é personalizável e, por padrão, é "Autenticador" concatenado com os últimos cinco caracteres do ID. Originalmente, o nome do autenticador era o ID completo e não podia ser alterado. Implementamos nomes personalizáveis para que o usuário possa rotular o autenticador com base nos recursos dele, no autenticador físico que ele pretende emular ou em qualquer apelido mais fácil de entender do que um ID de 36 caracteres.
Tabela de credenciais
Adicionamos uma tabela a cada seção de autenticador que mostra todas as credenciais registradas por um autenticador. Em cada linha, fornecemos informações sobre uma credencial, além de botões para remover ou exportar a credencial.
No momento, coletamos as informações para preencher essas tabelas pesquisando o CDP para receber as credenciais registradas de cada autenticador. No futuro, planejamos adicionar um evento para a criação de credenciais.
Botão "Ativo"
Também adicionamos um botão de opção Ativo a cada seção do autenticador. O autenticador que está definido como ativo será o único que detectará e registrará as credenciais. Sem isso, o registro de credenciais com vários autenticadores não é determinístico, o que seria uma falha fatal ao tentar testar o WebAuthn com eles.
Implementamos o status ativo usando o método SetUserPresence em autenticadores virtuais. O método SetUserPresence define se os testes de presença do usuário são bem-sucedidos para um determinado autenticador. Se ele for desativado, o autenticador não vai conseguir detectar credenciais. Portanto, ao garantir que ele esteja ativado para no máximo um autenticador (aquele definido como ativo) e desativar a presença do usuário para todos os outros, podemos forçar o comportamento determinístico.
Um desafio interessante que enfrentamos ao adicionar o botão ativo foi evitar uma condição de corrida. Pense no seguinte cenário:
O usuário clica no botão de opção Ativo do autenticador X, enviando uma solicitação ao CDP para definir X como ativo. O botão de opção Ativo para X está selecionado, e todos os outros estão desmarcados.
Imediatamente depois, o usuário clica no botão de opção Ativo do autenticador Y, enviando uma solicitação ao CDP para definir Y como ativo. O botão de opção Ativo para Y está selecionado, e todos os outros, incluindo X, estão desmarcados.
No back-end, a chamada para definir Y como ativo é concluída e resolvida. Y está ativo, e todos os outros autenticadores não estão.
No back-end, a chamada para definir X como ativo é concluída e resolvida. X está ativo, e todos os outros autenticadores, incluindo Y, não estão.
A situação resultante é a seguinte: X é o autenticador ativo. No entanto, o botão de opção Ativo para X não está selecionado. Y não é o autenticador ativo. No entanto, o botão de opção Ativo para Y está selecionado. Há um conflito entre o front-end e o status real dos autenticadores. Obviamente, isso é um problema.
Nossa solução: estabelecer uma comunicação pseudo bidirecional entre os botões de opção e o autenticador ativo. Primeiro, mantemos uma variável activeId
na visualização para acompanhar o ID do autenticador ativo no momento. Em seguida, esperamos que a chamada defina um autenticador ativo para retornar e defina activeId
como o ID desse autenticador. Por fim, percorremos cada seção do autenticador. Se o ID dessa seção for igual a activeId
, vamos definir o botão como selecionado. Caso contrário, definimos o botão como desmarcado.
Confira como isso funciona:
async _setActiveAuthenticator(authenticatorId) {
await this._clearActiveAuthenticator();
await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
this._activeId = authenticatorId;
this._updateActiveButtons();
}
_updateActiveButtons() {
const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
Array.from(authenticators).forEach(authenticator => {
authenticator.querySelector('input.dt-radio-button').checked =
authenticator.getAttribute('data-authenticator-id') === this._activeId;
});
}
async _clearActiveAuthenticator() {
if (this._activeId) {
await this._model.setAutomaticPresenceSimulation(this._activeId, false);
}
this._activeId = null;
}
Métricas de uso
Queríamos acompanhar o uso desse recurso. Inicialmente, criamos duas opções.
Conte cada vez que a guia WebAuthn no DevTools foi aberta. Essa opção pode levar a um supercontagens, já que alguém pode abrir a guia sem realmente usá-la.
Acompanhe o número de vezes que a caixa de seleção "Ativar ambiente do autenticador virtual" na barra de ferramentas foi ativada. Essa opção também tinha um possível problema de contagem excessiva, já que alguns usuários podem ativar e desativar o ambiente várias vezes na mesma sessão.
No final, optamos por usar a segunda opção, mas restringimos a contagem fazendo uma verificação para saber se o ambiente já estava ativado na sessão. Portanto, só aumentaríamos a contagem em 1, independentemente de quantas vezes o desenvolvedor alternasse o ambiente. Isso funciona porque uma nova sessão é criada sempre que a guia é reaberta, redefinindo a verificação e permitindo que a métrica seja incrementada novamente.
Resumo
Agradecemos a atenção. Se você tiver sugestões para melhorar a guia "WebAuthn", informe-nos enviando um bug.
Confira alguns recursos se quiser saber mais sobre o WebAuthn:
- Documento de design front-end do WebAuthn DevTools
- Documento de design da API de testes de autenticação na Web
- Especificação da API Web Authentication (WebAuthn)
- Explicação e guia da WebAuthn
Fazer o download dos canais de visualização
Use o Chrome Canary, Dev ou Beta como navegador de desenvolvimento padrão. Esses canais de visualização dão acesso aos recursos mais recentes do DevTools, permitem testar APIs de plataforma da Web de última geração e ajudam a encontrar problemas no seu site antes que os usuários.
Entre em contato com a equipe do Chrome DevTools
Use as opções a seguir para discutir os novos recursos, atualizações ou qualquer outra coisa relacionada ao DevTools.
- Envie feedback e solicitações de recursos para crbug.com.
- Informe um problema do DevTools usando a opção Mais opções > Ajuda > Informar um problema do DevTools no DevTools.
- Envie um tweet para @ChromeDevTools.
- Deixe comentários nos vídeos Novidades do DevTools no YouTube ou Dicas do DevTools no YouTube.