Como o Login Sem Senha Funciona nos Bastidores
Você clica em “Entrar”, seu telefone solicita uma impressão digital e você está autenticado. Nenhuma senha digitada, nenhum código copiado de um e-mail. Se você já implementou fluxos de autenticação antes, isso provavelmente parece mágica—ou pior, uma caixa preta que você deve integrar sem entender.
Este artigo explica como as passkeys e o WebAuthn realmente funcionam por trás das APIs do navegador. Você entenderá o fluxo de autenticação, as primitivas criptográficas envolvidas e as propriedades de segurança que tornam a autenticação sem senha baseada em FIDO2 fundamentalmente diferente de abordagens mais antigas como magic links ou OTPs.
Principais Conclusões
- Passkeys usam criptografia de chave pública onde a chave privada nunca sai do seu dispositivo, eliminando segredos compartilhados que invasores podem interceptar ou roubar.
- A autenticação WebAuthn envolve quatro partes: seu frontend, a API do navegador, o autenticador (chaveiro do dispositivo ou chave de hardware) e seu servidor.
- A vinculação de origem fornece resistência criptográfica a phishing—as credenciais são vinculadas a domínios específicos e não funcionarão em sites semelhantes.
- A interface condicional (Conditional UI) permite que prompts de passkey apareçam em sugestões de preenchimento automático, criando experiências de autenticação perfeitas.
Por Que as Passkeys Substituíram Métodos “Sem Senha” Anteriores
Magic links e senhas de uso único removeram o campo de senha dos formulários de login, mas não eliminaram os segredos compartilhados. Um magic link ainda é um token portador transmitido por e-mail—interceptável, reproduzível e vulnerável a phishing se os usuários clicarem em links em domínios falsificados. OTPs enviados via SMS são vulneráveis a ataques de troca de SIM (SIM-swapping).
As passkeys resolvem isso de forma diferente. Elas usam criptografia de chave pública onde o segredo (sua chave privada) nunca sai do seu dispositivo e nunca trafega pela rede. O servidor armazena apenas sua chave pública, que é inútil para invasores mesmo se o banco de dados for comprometido.
Este é o insight central por trás do FIDO2 e WebAuthn: a autenticação acontece através de prova criptográfica de posse, não transmissão de segredos.
O Fluxo de Autenticação WebAuthn
Quando um usuário se autentica com uma passkey, quatro componentes normalmente interagem: seu código frontend, a API WebAuthn do navegador, o autenticador (frequentemente o chaveiro do sistema operacional, um telefone ou uma chave de segurança de hardware) e seu servidor.
Registro: Criando a Credencial
Durante o registro, seu servidor gera um desafio (challenge)—uma sequência aleatória de bytes—e o envia ao navegador junto com seu ID de parte confiável (relying party ID, normalmente seu domínio). Seu frontend chama navigator.credentials.create() com esses parâmetros.
O navegador passa essa solicitação ao autenticador via CTAP (Client to Authenticator Protocol). O autenticador gera um novo par de chaves, armazena a chave privada com segurança e retorna a chave pública junto com uma atestação assinada.
Seu servidor recebe e armazena a chave pública, o ID da credencial e metadados como um contador de assinaturas. Nenhum hash de senha, nenhum segredo compartilhado—apenas uma chave pública vinculada ao seu domínio.
Autenticação: Provando a Posse
Quando o usuário retorna, seu servidor gera um novo desafio. Seu frontend chama navigator.credentials.get(), e o navegador solicita ao autenticador.
O autenticador encontra a credencial correspondente ao seu RP ID, requer verificação do usuário (biométrica, PIN ou presença), depois assina o desafio com a chave privada. Esta assinatura, junto com os dados do autenticador, retorna ao seu servidor.
Seu servidor verifica a assinatura contra a chave pública armazenada. Se corresponder, o usuário provou que possui a chave privada sem nunca transmiti-la.
Vinculação de Origem: O Mecanismo de Resistência a Phishing
Aqui está o que torna as passkeys genuinamente resistentes a phishing, em vez de apenas “mais difíceis de phishing”. O autenticador vincula criptograficamente as credenciais à origem da parte confiável.
Ao assinar o desafio, o autenticador inclui o hash do ID da parte confiável (derivado do seu domínio) nos dados assinados. Se um invasor criar um site semelhante em g00gle.com, a credencial para google.com simplesmente não funcionará—as origens não correspondem e o autenticador não produzirá uma assinatura válida.
Isso não é um aviso de interface que os usuários podem ignorar. É aplicado criptograficamente no nível do protocolo.
Discover how at OpenReplay.com.
Passkeys Sincronizadas vs. Vinculadas ao Dispositivo
As passkeys modernas normalmente sincronizam entre dispositivos através de chaveiros do sistema operacional—iCloud Keychain da Apple, Google Password Manager ou gerenciadores de terceiros como 1Password. Isso melhora drasticamente a usabilidade, pois os usuários não perdem acesso ao trocar de telefone.
Passkeys vinculadas ao dispositivo (como chaves de segurança de hardware) oferecem garantias mais fortes—a chave privada comprovadamente existe em exatamente um dispositivo. Para a maioria das aplicações web, passkeys sincronizadas fornecem segurança suficiente com melhor experiência do usuário. Seu modelo de ameaça determina qual é mais importante.
Padrões Modernos de UX: Interface Condicional
Você provavelmente já viu prompts de passkey aparecerem nas sugestões de preenchimento automático do campo de nome de usuário. Esta é a interface condicional (conditional UI)—o navegador oferece proativamente passkeys disponíveis antes que o usuário solicite explicitamente o login sem senha.
Implemente isso chamando navigator.credentials.get() com mediation: 'conditional' e adicionando autocomplete="username" ao seu campo de entrada.
O navegador cuida da descoberta e apresentação.
Muitas aplicações agora usam interface condicional para atualizar usuários existentes: após um login bem-sucedido com senha, solicite aos usuários que registrem uma passkey para sessões futuras.
Propriedades de Segurança e Limites de Confiança
As passkeys reduzem drasticamente a superfície de ataque, mas não são mágicas. A segurança da chave privada depende da implementação do autenticador—normalmente o enclave seguro do dispositivo ou TPM. Se o próprio dispositivo estiver comprometido no nível de hardware, todas as apostas estão canceladas.
A recuperação de conta permanece um desafio de design. Quando os usuários perdem todos os seus dispositivos, você precisa de mecanismos de fallback que não reintroduzam as vulnerabilidades que as passkeys eliminaram.
O WebAuthn continua evoluindo—Level 3 é a geração atual da especificação—com trabalho contínuo em autenticação entre dispositivos e atestação empresarial. Os fundamentos abordados aqui permanecem estáveis.
Conclusão
As passkeys mudam a autenticação de “verificar se o usuário conhece um segredo” para “verificar se o usuário possui uma chave”. Isso muda seu modelo mental: você não está verificando senhas contra hashes, você está verificando assinaturas criptográficas contra chaves públicas.
Para engenheiros frontend, a implicação prática é direta: aprenda as cerimônias de registro e autenticação da API WebAuthn, implemente interface condicional para descoberta perfeita e projete caminhos de atualização que movam os usuários de senhas para passkeys de forma incremental.
Perguntas Frequentes
A recuperação de conta se torna crítica quando os usuários perdem todos os dispositivos. Abordagens comuns incluem códigos de recuperação de backup gerados durante o registro, métodos de autenticação secundários como e-mail verificado ou processos de verificação de identidade. O desafio é projetar fallbacks que não reintroduzam as vulnerabilidades que as passkeys eliminaram, como magic links vulneráveis a phishing ou códigos SMS interceptáveis.
Sim, as passkeys são projetadas para compatibilidade multiplataforma. Passkeys sincronizadas armazenadas em chaveiros de plataforma como iCloud Keychain ou Google Password Manager funcionam entre dispositivos dentro desse ecossistema. Para autenticação entre ecossistemas, os usuários podem escanear códigos QR para autenticar usando uma passkey armazenada em um dispositivo diferente, aproveitando o protocolo de transporte híbrido FIDO2.
Cada credencial de passkey é única e vinculada a uma conta de usuário específica e parte confiável. Quando existem múltiplas passkeys para o mesmo domínio, o navegador ou autenticador apresenta uma interface de seleção permitindo que os usuários escolham qual credencial usar. O ID da credencial armazenado no servidor mapeia cada passkey para sua conta de usuário correspondente.
As passkeys resistem a ataques man-in-the-middle através da vinculação de origem. O autenticador inclui a origem exata na resposta de autenticação assinada. Se um invasor interceptar e retransmitir a tentativa de autenticação através de um proxy, a incompatibilidade de origem faz com que a verificação da assinatura falhe. A vinculação criptográfica torna os ataques de phishing em tempo real ineficazes.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
