Share via

APIs WebAuthn para autenticação sem senha no Windows

As senhas podem deixar seus clientes vulneráveis a violações de dados e ataques de segurança por usuários mal-intencionados.

A Microsoft tem sido um defensor da autenticação sem senha há muito tempo e introduziu as APIs da plataforma W3C/Fast IDentity Online 2 (FIDO2) Win32 WebAuthn em Windows 10 (versão 1903).

A partir de Windows 11, versão 22H2, as APIs WebAuthn dão suporte a algoritmos ECC.

O que isso significa?

Usando APIs WebAuthn, os parceiros de desenvolvedor e a comunidade de desenvolvedores podem usar Windows Hello ou chaves de segurança FIDO2 para implementar a autenticação multifator sem senha para seus aplicativos em dispositivos Windows.

Os usuários desses aplicativos ou sites podem usar qualquer navegador que dê suporte a APIs WebAuthn para autenticação sem senha. Os usuários terão uma experiência familiar e consistente no Windows, não importa qual navegador eles usem.

Os desenvolvedores devem usar as APIs WebAuthn para dar suporte a chaves de autenticação FIDO2 de forma consistente para os usuários. Além disso, os desenvolvedores podem usar todos os transportes disponíveis de acordo com as especificações FIDO2 (USB, NFC e BLE) evitando a sobrecarga de interação e gerenciamento.

Observação

Quando essas APIs estão em uso, Windows 10 navegadores ou aplicativos não têm acesso direto aos transportes FIDO2 para mensagens relacionadas ao FIDO.

O quadro geral

O Protocolo cliente para autenticador 2 (CTAP2) e o WebAuthn definem uma camada de abstração que cria um ecossistema para credenciais fortemente autenticadas. Nesse ecossistema, qualquer cliente interoperável (como um aplicativo nativo ou navegador) executado em um determinado dispositivo cliente usa um método padronizado para interagir com qualquer autenticador interoperável. Os autenticadores interoperáveis incluem autenticadores integrados ao dispositivo cliente (autenticadores de plataforma) e autenticadores que se conectam ao dispositivo cliente usando conexões USB, BLE ou NFC (autenticadores roaming).

O processo de autenticação começa quando o usuário faz um gesto de usuário específico que indica o consentimento para a operação. A pedido do cliente, o autenticador cria chaves criptográficas fortes e as armazena localmente.

Depois que essas chaves específicas do cliente forem criadas, os clientes poderão solicitar atestados para registro e autenticação. O tipo de assinatura que a chave privada usa reflete o gesto do usuário que foi feito.

O diagrama a seguir mostra como CTAP e WebAuthn interagem. As setas pontilhadas azul claro representam interações que dependem da implementação específica das APIs da plataforma.

O diagrama mostra como a API WebAuthn interage com as partes confiáveis e com a API CTAPI2.

Relações dos componentes que participam da autenticação sem senha

Uma dança WebAuthn/CTAP2 combinada inclui o seguinte elenco de caracteres:

  • Dispositivo cliente. O dispositivo cliente é o hardware que hospeda uma determinada autenticação forte. Laptops e telefones são exemplos de dispositivos cliente.

  • Festas e clientes confiáveis. As partes confiáveis são aplicativos web ou nativos que consomem credenciais fortes. As partes confiáveis são executadas em dispositivos cliente.

    • Como uma parte confiável, um aplicativo nativo também pode atuar como um cliente WebAuthn para fazer chamadas diretas do WebAuthn.

    • Como uma parte confiável, um aplicativo Web não pode interagir diretamente com a API WebAuthn. A parte confiável deve intermediar o negócio por meio do navegador.

    Observação

    O diagrama anterior não descreve a autenticação de SSO (Sign-On único). Tenha cuidado para não confundir as partes dependentes do FIDO com as partes dependentes federadas.

  • API WebAuthn. A API WebAuthn permite que os clientes façam solicitações para autenticadores. O cliente pode solicitar ao autenticador para criar uma chave, fornecer uma declaração sobre uma chave, recursos de relatório, gerenciar um PIN e assim por diante.

  • Plataforma/host CTAP2. A plataforma (também chamada de host na especificação CTAP2) é a parte do dispositivo cliente que negocia com autenticadores. A plataforma é responsável por relatar com segurança a origem da solicitação e por chamar as APIs de CBOR (Representação de Objeto Binário Conciso) CTAP2. Se a plataforma não estiver ciente do CTAP2, os próprios clientes assumirão mais a carga. Nesse caso, os componentes e interações mostrados no diagrama anterior podem ser diferentes.

  • Autenticador de plataforma. Um autenticador de plataforma geralmente reside em um dispositivo cliente. Exemplos de autenticadores de plataforma incluem a tecnologia de reconhecimento de impressão digital que usa um leitor de impressões digitais de laptop interno e uma tecnologia de reconhecimento facial que usa uma câmera de smartphone interna. Protocolos de transporte entre plataformas, como USB, NFC ou BLE, não podem acessar autenticadores de plataforma.

  • Autenticador roaming. Um autenticador roaming pode se conectar a vários dispositivos cliente. Os dispositivos cliente devem usar um protocolo de transporte com suporte para negociar interações. Exemplos de autenticadores de roaming incluem chaves de segurança USB, aplicativos de smartphone habilitados para BLE e cartões de proximidade habilitados para NFC. Os autenticadores de roaming podem dar suporte a CTAP1, CTAP2 ou ambos os protocolos.

Muitas partes e clientes confiáveis podem interagir com muitos autenticadores em um único dispositivo cliente. Um usuário pode instalar vários navegadores que dão suporte ao WebAuthn e, simultaneamente, ter acesso a um leitor de impressão digital interno, uma chave de segurança conectada e um aplicativo móvel habilitado para BLE.

Interoperabilidade

Antes de WebAuthn e CTAP2, havia U2F e CTAP1. U2F é a especificação universal de segundo fator da FiDO Alliance. Há muitos autenticadores que falam CTAP1 e gerenciam credenciais U2F. O WebAuthn foi projetado para ser interoperável com autenticadores CTAP1. Uma parte confiável que usa o WebAuthn ainda pode usar credenciais U2F se a parte confiável não exigir funcionalidade somente FIDO2.

Os autenticadores FIDO2 já foram implementados e as partes confiáveis do WebAuthn podem exigir os seguintes recursos opcionais:

As seguintes opções podem ser úteis no futuro, mas ainda não foram observadas na natureza:

  • Aprovação transacional
  • Índice de verificação do usuário (os servidores podem determinar se os dados biométricos armazenados localmente foram alterados ao longo do tempo)
  • Método de verificação de usuário (o autenticador retorna o método exato)
  • Limites de desempenho biométrico (a parte confiável pode especificar falsa aceitação aceitável e falsas taxas de rejeição)

Implementação da Microsoft

A implementação do Microsoft FIDO2 está há anos em andamento. Software e serviços são implementados independentemente como entidades compatíveis com padrões. A partir da versão Windows 10, versão 1809 (outubro de 2018), todos os componentes da Microsoft usam a versão mais recente do WebAuthn Candidate. É uma versão estável que não deve ser alterada normativamente antes que a especificação seja finalmente ratificada. Como a Microsoft está entre as primeiras do mundo a implantar o FIDO2, algumas combinações de componentes populares que não são da Microsoft ainda não serão interoperáveis.

Aqui está um layout aproximado de onde os bits da Microsoft vão:

O diagrama mostra como a API WebAuthn interage com as partes confiáveis da Microsoft e com a API CTAPI2.

Implementação da Microsoft de APIs WebAuthn e CATP2

  • Parte confiável do WebAuthn: Conta da Microsoft. Se você não está familiarizado com a Conta microsoft, é o serviço de entrada para Xbox, Outlook e muitos outros sites. A experiência de entrada usa o JavaScript do lado do cliente para disparar o Microsoft Edge para conversar com as APIs WebAuthn. A Conta microsoft exige que os autenticadores tenham as seguintes características:

    • As chaves são armazenadas localmente no autenticador e não em um servidor remoto
    • Os cenários offline funcionam (habilitados usando o HMAC)
    • Os usuários podem colocar chaves para várias contas de usuário no mesmo autenticador
    • Se for necessário, os autenticadores poderão usar um PIN do cliente para desbloquear um TPM

    Importante

    Como a Conta microsoft requer recursos e extensões exclusivos para autenticadores FIDO2 CTAP2, ele não aceita credenciais CTAP1 (U2F).

  • Cliente WebAuthn: Microsoft Edge. O Microsoft Edge pode lidar com a interface do usuário para os recursos WebAuthn e CTAP2 que este artigo descreve. Ele também dá suporte à extensão AppID. O Microsoft Edge pode interagir com autenticadores CTAP1 e CTAP2. Esse escopo de interação significa que ele pode criar e usar credenciais U2F e FIDO2. No entanto, o Microsoft Edge não fala o protocolo U2F. Portanto, as partes confiáveis devem usar apenas a especificação WebAuthn. O Microsoft Edge no Android não dá suporte ao WebAuthn.

    Observação

    Para obter informações autoritárias sobre o suporte do Microsoft Edge para WebAuthn e CTAP, confira Documentação do desenvolvedor herdado do Microsoft Edge.

  • Plataforma: Windows 10, Windows 11. Windows 10 e Windows 11 hospedar as APIs WebAuthn da Plataforma Win32.

  • Autenticadores de roaming. Você pode notar que não há nenhum autenticador de roaming da Microsoft . O motivo é porque já há um forte ecossistema de produtos especializados em autenticação forte, e cada cliente (sejam corporações ou indivíduos) tem requisitos diferentes para segurança, facilidade de uso, distribuição e recuperação de conta. Para obter mais informações sobre a lista crescente de autenticadores certificados pelo FIDO2, consulte Produtos Certificados FIDO. A lista inclui autenticadores internos, autenticadores roaming e até fabricantes de chips que têm designs certificados.

Referências do desenvolvedor

As APIs WebAuthn são documentadas no repositório GitHub da Microsoft/webauthn . Para entender como funcionam os autenticadores FIDO2, examine as duas especificações a seguir: