O que é autenticação sem senha (passwordless)?

Autenticação sem senha é um modelo de login que verifica a identidade com uma chave guardada no dispositivo ou biometria, em vez de um segredo memorizado. Na linguagem dos fatores: ela remove o “algo que você sabe” e autentica com “algo que você tem” e “algo que você é” — e, nas variantes mais fortes, não existe segredo compartilhado algum: o servidor armazena uma chave pública, a chave privada nunca sai do seu dispositivo, e não há nada para phishing, credential stuffing ou vazamento em massa. Senhas persistem não porque são boas, mas porque estão instaladas; o passwordless é a migração finalmente em andamento em escala.

Principais pontos

A cerimônia do WebAuthn, desmistificada

O maquinário por trás de todo prompt de passkey — duas cerimônias, nenhum segredo em trânsito:

REGISTRO                                  LOGIN
1 o servidor envia um desafio aleatório   1 o servidor envia um desafio novo
2 navigator.credentials.create()          2 navigator.credentials.get()
3 o dispositivo cria um par de chaves;    3 desbloqueio local por biometria/PIN,
  biometria ou PIN o protege                o dispositivo ASSINA o desafio
4 chave pública → servidor; a chave       4 o servidor verifica com a chave
  privada nunca sai do dispositivo          pública armazenada → session emitida

A credencial é vinculada à ORIGEM: um domínio imitador recebe uma
assinatura que não verifica em lugar nenhum. Essa propriedade — não a
biometria — é o que "resistente a phishing" significa.

A rampa mais suave que a maioria dos apps lança primeiro — magic links, onde a caixa de entrada é o fator:

// JavaScript / Node.js — Back4app JS SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await Parse.Cloud.run('requestMagicLink', { email: '[email protected]' });

// 2 · The link opens the app with the token; exchange it for a session
const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', {
  token: tokenFromLink, // single-use, expires in 15 minutes
});
await Parse.User.become(sessionToken); // logged in — no password exists

// Flutter / Dart — Back4app Flutter SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await ParseCloudFunction('requestMagicLink')
    .execute(parameters: {'email': '[email protected]'});

// 2 · The deep link opens the app with the token; exchange for a session
final result = await ParseCloudFunction('redeemMagicLink')
    .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min
// Adopt the returned session token — logged in, no password exists

// iOS / Swift — Back4app Swift SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
_ = try await Cloud.run(name: "requestMagicLink",
                        parameters: ["email": "[email protected]"])

// 2 · The universal link opens the app with the token; exchange for a session
let result = try await Cloud.run(name: "redeemMagicLink",
                                 parameters: ["token": tokenFromLink])
try await User.become(sessionToken: result["sessionToken"] ?? "")
// logged in — no password exists

// Android / Kotlin — Back4app Android SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
ParseCloud.callFunction<Map<String, Any>>(
    "requestMagicLink", mapOf("email" to "[email protected]"))

// 2 · The deep link opens the app with the token; exchange for a session
val result = ParseCloud.callFunction<Map<String, Any>>(
    "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min
ParseUser.becomeInBackground(result["sessionToken"] as String)
// logged in — no password exists

Passkeys vs. magic links vs. OTP: os métodos, ranqueados

Todo método passwordless herda a segurança de alguma coisa — a tabela diz de qual:

A linha que importa passa entre as duas primeiras fileiras e o resto: códigos, links e aprovações podem todos ser retransmitidos por um proxy de phishing ao vivo; assinaturas vinculadas à origem, não — a mesma linha divisória traçada no ranking de métodos do artigo de MFA, porque é a mesma linha.

Sincronizada ou vinculada ao dispositivo: o trade-off real

As passkeys se dividem em dois modelos de custódia, e a diferença é política, não pedantismo. Passkeys sincronizadas vivem em um gerenciador de credenciais e se replicam, criptografadas de ponta a ponta, entre os dispositivos do usuário — perder o telefone é um não evento, e foi por isso que a adoção pelo consumidor finalmente andou; a troca de confiança é que a conta de sincronização vira a joia da coroa, guardada pelos próprios fluxos de recuperação. Chaves vinculadas ao dispositivo (chaves de segurança de hardware, autenticadores com atestação corporativa) nunca saem do hardware — a escolha de alta garantia para admins e acessos regulados, com “cadastre uma reserva” como o plano de recuperação inteiro. As diretrizes atuais do NIST encerraram a discussão para o mainstream: autenticadores sincronizados são aceitáveis nos níveis de garantia padrão, com os vinculados ao dispositivo reservados ao nível mais alto.

O problema da recuperação, de novo

O passwordless afia a regra mais antiga da autenticação: a conta é tão forte quanto seu caminho de recuperação mais fraco. Um login por passkey com fallback de OTP por e-mail é, para um atacante, um login por OTP de e-mail com etapas extras. Não existe “redefinir” para uma chave vinculada ao dispositivo — por design — então a disciplina é antecipada: cadastre dois ou mais autenticadores em dispositivos separados na configuração, emita códigos de recuperação offline, trate métodos de fallback como decisões de segurança e não como conveniências de suporte, e faça da remoção de um autenticador um evento com step-up, registrado e que dispara alerta. Implantações que pulam isso reaprendem pela via do help desk.

Não é versus MFA — é uma fusão

O enquadramento “passwordless vs. MFA” das páginas de comparação de fornecedores é um falso binário. MFA significa múltiplas categorias de fator; passwordless significa nenhum segredo memorizado. Uma passkey desbloqueada por digital é as duas coisas: posse do dispositivo mais inerência no desbloqueio — multifator em um único gesto, com o elemento phishável excluído em vez de complementado. A consequência prática: organizações não escolhem entre os dois; elas migram de “senha + segundo fator” para “passkey”, que é um ponto estritamente mais forte na mesma curva.

Casos de uso comuns

• Login de app de consumo — passkeys como caminho promovido; magic links como fallback de baixa fricção.
• Comércio de visita recorrente — onde a fricção do login é receita mensurável, o login em um gesto paga o próprio custo.
• Acesso da força de trabalho — autenticadores resistentes a phishing como política para admins e papéis de alto privilégio.
• Produtos passwordless-first — onboarding por link de e-mail ou OTP sem nunca lançar um campo de senha.
• Momentos de step-up — uma cerimônia de passkey como reautenticação antes de pagamentos, exclusões e exportações de chaves.

Você deveria adotar o passwordless? Matriz de decisão

Limitações e trade-offs

• A cobertura não é universal. Nem todo site, navegador e stack corporativo suporta passkeys ainda; senhas permanecem como andaime de compatibilidade — por isso a coexistência vence a migração em precipício.
• O ecossistema guarda as chaves. Passkeys sincronizadas delegam a custódia aos gerenciadores de credenciais das plataformas — uma dependência de disponibilidade e confiança que você herda em vez de operar.
• Recuperação é o projeto de verdade. A cerimônia mais forte com um caminho de reset fraco é teatro; orce a UX de cadastro e a política de fallback, não só a integração WebAuthn.
• Passwordless mais fraco continua mais fraco. Magic links e SMS removem a senha sem adicionar resistência a phishing — um upgrade, não o destino.
• Os modelos de suporte mudam. Chamados de “esqueci a senha” viram chamados de “perdi o dispositivo”; help desks precisam de procedimentos de verificação que não virem o novo buraco de engenharia social.

Passwordless no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Passwordless aqui é um padrão que você compõe a partir dos primitivos da plataforma, e as abas de código mostram o canônico: um fluxo de magic link construído com duas funções de Cloud Code — requestMagicLink gera um token de uso único e expiração curta, o armazena no usuário e envia o link por e-mail; redeemMagicLink o valida no servidor e devolve um token de sessão que o SDK adota, de modo que o cliente nunca manipula credenciais. Além dos links, os adaptadores de auth customizados do Back4app conectam provedores de OTP e passkey ao mesmo mecanismo de authData que move o login social — um objeto de usuário, vários métodos de login, vinculáveis e desvinculáveis por usuário, que é a disciplina de recuperação (múltiplos métodos cadastrados) expressa como modelagem de dados. As sessions seguem revogáveis o tempo todo: seja qual for a cerimônia, a credencial que ela emite pode ser morta no momento em que algo parecer errado.