TL;DR
É a pergunta que trava a primeira semana de muito MVP: passkey, magic link ou senha? Resposta curta: passkey quando a conta guarda algo que dói perder, magic link quando o usuário entra de vez em quando, senha só com um motivo concreto. Mas essa nem é a decisão que importa. A tela de login é a parte fácil dos três. O que custa caro é o resto do ciclo da conta: recuperar acesso, expirar sessão, revogar device, migrar quem já entrou. É onde o MVP trava depois, com usuário real preso do lado de fora.
Por que a tela de login é a parte fácil
Autenticação parece uma tela e é um subsistema. A tela valida credencial e abre sessão, coisa que qualquer framework moderno resolve em poucas linhas. O trabalho de verdade está em recuperação de conta, renovação e expiração de sessão, revogação de acesso e o que acontece quando o usuário troca de celular. Nada disso aparece no caminho feliz.
Isso ficou mais visível agora que dá pra pedir “coloca login no meu app” e receber algo funcionando em minutos. Eu acho isso ótimo, e não é sarcasmo: o custo de escrever o fluxo despencou. Só que o que veio pronto é o caminho feliz, aquele em que a pessoa cadastra, confirma e entra. O caminho infeliz continua na sua conta.
“Mas o login está funcionando.” Está. Funcionar no dia do cadastro é o requisito mais fácil que existe.
Login quebra depois, não no dia 1.
Passkey, magic link ou senha: o que cada um cobra de você
Cada um resolve o mesmo problema (provar que a pessoa é ela) cobrando um preço diferente, e o preço quase nunca é o de implementar. Passkey é uma credencial criptográfica guardada no device ou no chaveiro do sistema operacional, sem segredo compartilhado com o seu servidor. Ela roda sobre o WebAuthn, a API de autenticação padronizada pelo W3C e implementada pelos navegadores e sistemas grandes, com o ecossistema de passkey mantido pela FIDO Alliance.
- Passkey. O usuário desbloqueia com biometria ou PIN do próprio aparelho e você nunca guarda segredo reutilizável. Mata phishing e vazamento de base de senha de uma vez. Cobra de volta em suporte: quem não entendeu o que é aquilo, quem não tem o chaveiro sincronizado, quem quer entrar do computador do trabalho.
- Magic link. Simples de implementar e sem senha pra esquecer. O preço é que seu login passa a depender de entrega de e-mail, com filtro de spam, atraso e link que abre no navegador errado. Em app com webview e em rede corporativa, é onde o suporte mais apanha.
- Senha com segundo fator. O modelo que TODO usuário sabe operar e todo time sabe manter. Cobra em superfície de ataque: reuso de senha, credential stuffing e o custo permanente de tratar hash, rotação e bloqueio direito.
- Login social. Rápido e com atrito baixíssimo no cadastro, e você terceiriza a identidade pra um provedor. O preço aparece quando o usuário perde acesso àquela conta, quando a conta corporativa dele é desativada, ou quando o provedor muda regra de escopo no meio do caminho.
| Método | Melhor quando | Custo escondido |
|---|---|---|
| Passkey | a conta guarda dinheiro ou dado sensível | suporte a quem perde ou não sincroniza o device |
| Magic link | o usuário entra de vez em quando | entregabilidade de e-mail e webview |
| Senha + MFA | o público é amplo e pouco técnico | ataque a credencial e manutenção do fluxo |
| Login social | cadastro precisa ser instantâneo | dependência de conta que não é sua |
Repare que a coluna que decide é a terceira. A primeira todo mundo olha na hora de escolher, a terceira chega junto com os usuários.
O que ninguém implementa no primeiro dia
Essa é a lista que separa login de produto de login de demo. Nenhum desses itens é sobre qual método você escolheu, e é por isso que a discussão passkey contra magic link costuma ser a discussão errada.
- Recuperação de conta. O usuário perdeu o device com a passkey, ou o e-mail do magic link é o antigo da empresa dele. Se a sua recuperação é “manda link pro e-mail”, então o seu login é o e-mail dele, com passkey ou sem. A força do método principal não passa da força do caminho de recuperação.
- Sessão e revogação. Quanto tempo a sessão dura, o que renova, e como você derruba todas as sessões quando alguém pede. Sem isso, “sair de todos os dispositivos” vira um botão que não faz nada de verdade.
- Multi-device de gente real. A pessoa cadastrou no celular e agora abriu no notebook. Passkey sincroniza no chaveiro dela, ou você precisa de um fluxo pra registrar o segundo device sem transformar isso num cadastro novo.
- Migração de quem já entrou. MVP com senha que decide adotar passkey depois precisa conviver com os dois por um tempo. Trocar método com base de usuário viva é um projeto, não uma flag.
- Bloqueio e tentativa. Limite de tentativa, detecção de força bruta, o que acontece com a conta travada às 3h da manhã. Falha de identificação e autenticação é categoria própria no OWASP Top 10, e quase tudo dela mora aqui, não na tela.
Onde isso quebra
Passkey não resolve tudo, e eu prefiro dizer isso antes de você trocar o fluxo inteiro. O ganho de segurança é real e o atrito também: parte do seu público vai chegar num aparelho emprestado, num desktop antigo ou num ambiente corporativo travado, e vai precisar de um plano B. Se o plano B for e-mail sem cuidado, você gastou esforço pra ficar no mesmo lugar.
Magic link quebra de um jeito mais chato porque quebra fora do seu código. O link atrasou, caiu no spam, abriu no navegador interno de um app e criou sessão no lugar errado. Você vai debugar entrega de e-mail achando que está debugando autenticação.
Senha quebra devagar. Ninguém liga pra reclamar que o hash está fraco ou que não existe bloqueio por tentativa. Você descobre junto com o incidente, e aí não é mais bug, é aviso pra base inteira.
O ponto comum: NENHUM desses métodos é errado. Errado é escolher um pelo que ele custa pra implementar e ignorar o que ele custa pra operar.
O que decidir antes de escrever a primeira linha
“Isso não é decisão de MVP, é over-engineering.” Discordo, e por um motivo bem prático.
Auth é das poucas decisões que ficam caras de desfazer, porque a base de usuário viva vai junto. Escolher errado o banco você troca com migration. Escolher errado o login você negocia com gente que já entrou. Eu separo o que decidir cedo do que dá pra adiar do mesmo jeito que faço em monólito modular ou microsserviços: o que é reversível espera, o que arrasta usuário junto não espera.
Quatro perguntas resolvem a escolha na maioria dos casos:
- O que a conta guarda? Dinheiro, dado de terceiro ou saúde do negócio do cliente puxam pra passkey com segundo caminho bem feito.
- Com que frequência a pessoa entra? Uso diário aguenta método com registro inicial mais chato. Uso mensal favorece magic link.
- Quem é o usuário? Público técnico adota passkey rápido. Público amplo e pouco técnico ainda espera senha, e forçar o novo sem plano B vira churn silencioso no cadastro.
- Quem atende quando trava? Se não existe alguém pra responder o “não consigo entrar”, escolha o método com menos caminhos de recuperação, não o mais moderno.
Na Nextside a gente considera login entregue quando o ciclo inteiro passa no aceite, não quando a tela abre, com o preço travado antes de existir código. Isso vale ainda mais quando o fluxo nasceu de um agente: o mesmo cuidado que eu descrevo em segurança de agente de IA se aplica ao que ele escreveu no seu fluxo de conta.
O que a escolha de login diz sobre o produto
Time que discute passkey contra magic link por três dias e não escreve uma linha sobre recuperação de conta está otimizando a parte visível. É a mesma armadilha de cortar a coisa errada no MVP, que eu já detalhei em o que cortar e o que manter: o que fica de fora nunca é o que aparece na demo.
Escolhe o método pelo usuário que você tem, não pelo que está em alta. Depois trata o ciclo da conta como feature de verdade, com prazo e responsável. Login não é a porta, é a chave que a pessoa vai perder um dia.
FAQ
O que é uma passkey e como ela funciona?
Passkey é uma credencial criptográfica guardada no device ou no chaveiro do sistema operacional do usuário. Ele desbloqueia com biometria ou PIN e o servidor valida uma assinatura, sem guardar segredo reutilizável. Roda sobre o padrão WebAuthn, mantido pelo W3C, com o ecossistema de passkey definido pela FIDO Alliance.
Passkey ou magic link: qual escolher no MVP?
Passkey quando a conta guarda dinheiro ou dado sensível e o usuário entra com frequência. Magic link quando o acesso é esporádico e o cadastro precisa ser simples. A pergunta que decide não é qual é mais seguro no papel, é qual caminho de recuperação você consegue manter quando o usuário perde o acesso.
Senha ainda faz sentido em produto novo?
Faz, principalmente com público amplo e pouco técnico, desde que venha com segundo fator, hash adequado e bloqueio por tentativa. O problema da senha nunca foi ela existir, foi ela ser o único fator e ser reusada em vários serviços. Senha bem operada perde para passkey, mas ganha de passkey mal operada.
Dá para trocar o método de login depois?
Dá, e custa mais do que parece. Com base de usuário viva você precisa conviver com os dois métodos por um período, migrar sem deslogar todo mundo e manter os dois caminhos de recuperação funcionando. Por isso vale decidir com critério antes, mesmo em MVP: é decisão que arrasta usuário junto.
O que mais quebra em autenticação de MVP?
Recuperação de conta, disparado. Depois vêm sessão sem expiração ou sem revogação real, ausência de bloqueio por tentativa e o segundo device do mesmo usuário. Falha de identificação e autenticação é categoria própria no OWASP Top 10, e a maior parte dela está nesses caminhos, não na tela de login.