Passkeys em sites: cadastro, login e recuperação sem senha

Para adicionar passkeys a um site sem criar um problema de recuperação, trate a credencial como parte do ciclo de vida da conta: cadastro verificado, login, gestão de dispositivos, método alternativo e resposta à perda de acesso. Uma passkey permite autenticar sem digitar uma senha, mas não dispensa um processo seguro para cadastrar uma nova credencial quando a anterior deixa de estar disponível.

O desenho recomendado é adotar passkeys de forma progressiva, manter temporariamente os métodos existentes com controles proporcionais ao risco e permitir mais de uma passkey por conta. A decisão sobre recuperação precisa vir antes de retirar a senha.

O que muda com passkeys e WebAuthn

Uma passkey usa criptografia de chave pública. O provedor da passkey guarda a chave privada; o servidor do site armazena a chave pública associada à conta. Após o desbloqueio local com biometria, PIN ou outro mecanismo do dispositivo, o autenticador assina um desafio, que o servidor verifica. A biometria não é enviada ao site. A credencial é vinculada ao domínio, o que reduz a exposição a phishing. O guia de cadastro do web.dev, atualizado em 9 de abril de 2026, explica esse fluxo.

Passkey não é sinônimo de uma cópia por aparelho. Há credenciais sincronizadas por um provedor e credenciais vinculadas a dispositivo, como certas chaves físicas. O produto precisa comunicar essa diferença sem prometer que toda passkey aparecerá automaticamente em outro equipamento.

Arquitetura: navegador, provedor e servidor

Projete uma relação de uma conta para várias credenciais. Para cada registro, mantenha no mínimo ID da credencial, ID interno estável do usuário, chave pública, dados necessários à verificação e datas de criação e último uso. Nome amigável, AAGUID e indicação de elegibilidade para backup podem ajudar a interface de gestão; AAGUID é metadado de apresentação, não prova de identidade do dispositivo. Defina previamente o RP ID e as origens HTTPS permitidas; o backend deve verificar os valores esperados, não aceitar os enviados pelo cliente sem validação.

Cadastro: vincular uma passkey à conta certa

1. Confirme que a pessoa controla a conta por uma sessão recente e verificação adequada ao risco. Evite autorizar uma nova passkey apenas com uma senha possivelmente comprometida.
2. O servidor gera um desafio novo e as opções de criação, incluindo RP ID, identificador estável do usuário e credenciais existentes a excluir quando aplicável.
3. O navegador chama navigator.credentials.create(); o provedor cria o par de chaves após a interação local.
4. O frontend envia a resposta ao backend, que valida desafio, origem, RP ID, tipo e requisitos de verificação do usuário com uma biblioteca WebAuthn mantida e só então salva a chave pública.
5. Confirme o cadastro na interface, notifique a pessoa por canal já cadastrado e ofereça o registro de uma segunda passkey ou método de backup.

Se a pessoa cancelar a operação ou o servidor não salvar a credencial, apresente uma mensagem de erro recuperável. Não marque o cadastro como concluído apenas porque o navegador retornou uma credencial. A documentação de registro também recomenda sinalizar credenciais desconhecidas quando houver suporte do navegador.

Login: verificar a assinatura e criar a sessão

1. O servidor entrega um desafio novo e de curta duração para a autenticação.
2. O navegador chama navigator.credentials.get() e a pessoa escolhe uma passkey e confirma o desbloqueio local.
3. O backend localiza a credencial pelo ID, confere desafio, origem, RP ID, assinatura e política de verificação do usuário, além de impedir reutilização do desafio.
4. Somente após validação bem-sucedida o servidor cria uma sessão segura e registra o uso da credencial.

Não confunda o resultado visual de biometria com autenticação concluída: quem decide o acesso é a verificação criptográfica no servidor. Para o login com descoberta de conta, a aplicação pode usar credenciais descobríveis sem pedir o e-mail antes, conforme o desenho do fluxo.

Múltiplos dispositivos e gestão da conta

Disponibilize uma área autenticada para adicionar, nomear e remover passkeys, com provedor aproximado e datas relevantes. Incentive uma segunda opção em outro provedor ou uma chave física quando fizer sentido. Uma passkey sincronizada pode aparecer em novos dispositivos após o usuário recuperar o acesso ao próprio provedor; uma chave vinculada a um dispositivo não oferece essa mesma garantia. O guia de gestão de passkeys do web.dev recomenda múltiplas credenciais e alerta sobre excluir a última.

Permita autenticação entre dispositivos, quando disponível, e depois ofereça criar uma passkey no aparelho atual. Antes de remover a última credencial, explique qual será o caminho de login restante. A exclusão no servidor impede seu uso no site, mas pode não apagar imediatamente a cópia armazenada no provedor; use a Signal API quando suportada e oriente a remoção manual quando necessário.

Fallback progressivo sem enfraquecer o login

Na migração, o mesmo formulário pode oferecer passkey e senha com preenchimento automático. O fluxo de interface condicional usa o campo de usuário com autocomplete="username webauthn" e uma chamada WebAuthn com mediation: "conditional". Se a pessoa escolher senha, o formulário convencional continua. Mantenha também um botão explícito de passkey e uma alternativa clara quando não houver suporte ou credencial disponível. Veja o guia de login por preenchimento automático.

Enquanto existirem senhas legadas, proteja-as com MFA e as defesas normais de autenticação. Não apresente um link por e-mail ou um SMS como proteção equivalente à passkey: métodos alternativos podem reintroduzir phishing e tomada de conta. Aplique verificação adicional a operações sensíveis, inclusive inclusão ou exclusão de credenciais.

Recuperação: o que fazer quando a passkey sumiu

Separe recuperar o provedor de recuperar a conta do site. Um link de recuperação pode iniciar uma sessão restrita ao processo, mas não deve conceder automaticamente uma sessão plena nem autorizar inclusão de passkey em contas sensíveis sem controles adicionais. Use respostas genéricas para não revelar contas existentes, limitação de tentativas e tokens aleatórios, de uso único e com expiração. Depois da verificação, exija nova autenticação, notifique sobre a mudança, permita revisar sessões e revogue credenciais comprometidas. As orientações da OWASP sobre recuperação e da FIDO Alliance sobre recuperação com passkeys ajudam a definir a política conforme o risco.

Checklist de UX e segurança antes de publicar

• Confirmar HTTPS, RP ID, origens e validação de desafios no backend; usar biblioteca WebAuthn mantida.
• Testar cadastro, login, cancelamento, erro de rede, credencial ausente e navegador sem suporte.
• Definir se a verificação local do usuário é obrigatória; conferir o sinal de verificação na resposta, em vez de presumir que sempre ocorreu.
• Permitir várias passkeys por conta, exibir a lista e tratar com cuidado a remoção da última.
• Proteger cadastro, exclusão e recuperação com reautenticação e controles proporcionais ao risco.
• Testar aparelho novo, sincronização indisponível, uso entre dispositivos, perda total de acesso e credencial revogada.
• Registrar eventos de segurança sem armazenar segredos, desafios, tokens de recuperação ou dados biométricos em logs.

Uma migração segura termina quando a pessoa consegue entrar, identificar suas credenciais e recuperar a conta por um caminho deliberadamente desenhado. A ausência de senha na tela não significa, sozinha, que o risco de tomada de conta desapareceu.