--- term: 'Autenticação Sem Senha (Passwordless)' seoTitle: 'Autenticação Sem Senha: Passkeys, Magic Links, WebAuthn' headline: 'O que é autenticação sem senha (passwordless)?' slug: autenticacao-sem-senha category: auth-security shortDefinition: '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.' relatedTerms: - multi-factor-authentication-mfa - oauth-2-social-login - json-web-token-jwt - identity-access-management-iam contrastsWith: - multi-factor-authentication-mfa aboutTerms: - 'Passkeys' - 'WebAuthn' - 'Magic Links' faq: - question: 'O que é autenticação sem senha em termos simples?' answer: 'Fazer login sem digitar senha: você prova a identidade com algo que tem — um dispositivo guardando uma chave criptográfica, uma caixa de entrada, uma chave de segurança — ou com algo que é, pela biometria que a desbloqueia. A propriedade definidora: não existe segredo compartilhado para alguém roubar, reutilizar ou capturar por phishing.' - question: 'Autenticação sem senha é mais segura que senha?' answer: 'Contra os ataques que de fato causam violações — phishing, credential stuffing, reutilização, força bruta — decisivamente, porque não há segredo para roubar do servidor nem para arrancar do usuário. Não é inhackeável: códigos podem ser interceptados, dispositivos roubados, e caminhos de recuperação fracos minam portas de entrada fortes.' - question: 'O que é passkey e como funciona?' answer: 'Credenciais FIDO construídas sobre o WebAuthn. No registro, seu dispositivo cria um par de chaves e envia ao site apenas a chave pública; no login, o dispositivo assina o desafio do site após um desbloqueio local por biometria ou PIN. A credencial é vinculada ao domínio real, então um site imitador recebe uma assinatura que não vale nada — a origem da resistência a phishing.' - question: 'Qual a diferença entre passkey sincronizada e vinculada ao dispositivo?' answer: 'Passkeys sincronizadas são cópias criptografadas de ponta a ponta distribuídas por um gerenciador de credenciais — sobrevivem à perda do dispositivo e facilitam a recuperação, ao preço de confiar na conta de sincronização. Chaves vinculadas ao dispositivo nunca saem do hardware — a maior garantia, sem cópia de recuperação. As diretrizes federais atuais aceitam passkeys sincronizadas nos níveis de garantia convencionais.' - question: 'Magic link é seguro?' answer: 'Mais seguro que senha para a maioria dos usuários, e exatamente tão seguro quanto a caixa de entrada onde cai — o e-mail é o autenticador de verdade, e é por isso que as diretrizes de identidade o tratam como canal restrito. A higiene: tokens de uso único, expiração curta, geração aleatória, links só em HTTPS.' - question: 'Passwordless é o mesmo que MFA?' answer: 'Não, e o enquadramento popular de um-ou-outro é falso: MFA adiciona fatores, passwordless remove o fator memorizado — e uma passkey desbloqueada por biometria é as duas coisas ao mesmo tempo: posse do dispositivo mais a inerência que o desbloqueia, multifator em um único gesto e sem senha em lugar nenhum.' - question: 'O que acontece se eu perder meu dispositivo?' answer: 'Passkeys sincronizadas se restauram pelo gerenciador de credenciais; chaves vinculadas ao dispositivo não — por design. A disciplina: cadastre pelo menos dois autenticadores em dispositivos separados, guarde códigos de recuperação offline e lembre que um fallback fraco — OTP por e-mail atrás de uma passkey — limita silenciosamente a conta inteira à força do fallback.' - question: 'Como adicionar login sem senha a um app?' answer: 'Como adição, não como precipício: mantenha o login existente, ofereça passkeys ou magic links como caminho preferido, cadastre um fallback na configuração e rebaixe a senha depois. Para WebAuthn, use uma biblioteca de servidor open-source mantida para a verificação da cerimônia, em vez de implementar na mão as checagens de desafio e origem.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'W3C Web Authentication (WebAuthn) Level 3' url: 'https://www.w3.org/TR/webauthn-3/' - name: 'FIDO Alliance — Passkeys' url: 'https://fidoalliance.org/passkeys/' - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication' url: 'https://pages.nist.gov/800-63-4/sp800-63b.html' - name: 'CISA — Implementing Phishing-Resistant MFA' url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf' - name: 'Passwordless authentication — Wikipedia' url: 'https://en.wikipedia.org/wiki/Passwordless_authentication' cta: title: 'Passwordless a uma Cloud Function de distância' text: 'Construa login por magic link no Back4app com Cloud Code — geração de token, e-mail e emissão de session no servidor — ou conecte qualquer provedor de OTP e passkey pelos adaptadores de auth customizados do Back4app.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: passwordless-authentication --- **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 | Pergunta | Resposta | | --- | --- | | A troca | Sai o fator de conhecimento; entram posse + inerência | | O padrão-ouro | Passkeys (FIDO2/WebAuthn) — chaves vinculadas à origem, resistentes a phishing | | O gradiente honesto | Passkeys > push/TOTP > magic links > SMS — cada um herda algo | | vs. MFA | Rivalidade falsa — uma passkey com biometria *é* MFA, menos a senha | | O elo fraco | Recuperação — um fallback mais fraco que a porta da frente vira a porta | ## 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: ```text 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:** ```javascript // 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: 'ada@example.com' }); // 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 // 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': 'ada@example.com'}); // 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 ``` **Swift:** ```swift // 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": "ada@example.com"]) // 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 ``` **Kotlin:** ```kotlin // 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>( "requestMagicLink", mapOf("email" to "ada@example.com")) // 2 · The deep link opens the app with the token; exchange for a session val result = ParseCloud.callFunction>( "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: | Método | Fator | Resistente a phishing? | Herda o risco de | História de recuperação | | --- | --- | --- | --- | --- | | **Passkey (sincronizada)** | Tem + é | **Sim** — vinculada à origem | A conta do gerenciador de credenciais | Restaura entre dispositivos | | **Chave de segurança (vinculada ao dispositivo)** | Tem (+ é) | **Sim** | A custódia física | Nenhuma — cadastre uma reserva | | Código TOTP / autenticador | Tem | Não — códigos podem ser retransmitidos | O segredo do cadastro | Recadastrar | | Aprovação por push | Tem | Não — e bombardeável | A atenção do usuário | Recadastrar | | Magic link | Tem (caixa de entrada) | Não | **Sua conta de e-mail** | Ele *é* o caminho de recuperação | | Código único por SMS | Tem (número) | Não | A operadora — SIM swap | O mais fraco do conjunto | 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](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) — a mesma linha divisória traçada no [ranking de métodos do artigo de MFA](/glossary/pt/autenticacao-multifator-mfa/), porque é a mesma linha. ```mermaid flowchart LR accTitle: Por que uma passkey derrota um proxy de phishing accDescr: Com uma passkey, o dispositivo assina um desafio vinculado à origem genuína, então um site falso que retransmite o login recebe uma assinatura que falha na verificação. Com um código de uso único, a vítima pode ser enganada a digitá-lo no site falso, que o retransmite ao site real com sucesso. V["Vítima"] -->|"digita o código OTP"| F["Site falso
(proxy)"] -->|"retransmite — funciona"| R["Site real"] V2["Vítima com passkey"] -->|"o dispositivo assina para
a origem FALSA"| F2["Site falso"] -.->|"assinatura inválida
na origem real"| X["Falha"] ``` ## 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](https://pages.nist.gov/800-63-4/sp800-63b.html) 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](/glossary/pt/autenticacao-multifator-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 | Situação | Tendência | | --- | --- | | App de consumo novo | Passkeys + fallback de magic link; pule o campo de senha | | App existente, base grande de usuários | Coexistência: adicione passkeys como preferência, rebaixe senhas depois | | Contas de admin / alto privilégio | Só resistente a phishing — passkeys ou chaves de hardware | | Público em dispositivos compartilhados ou antigos | Magic links / OTP com expectativas honestas | | Acesso regulado, de alta garantia | Autenticadores vinculados ao dispositivo, atestação, reservas cadastradas | | "Só adicionar segurança nesta sprint" | [MFA no login existente](/glossary/pt/autenticacao-multifator-mfa/) agora; passwordless em seguida | ## 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](/glossary/pt/gerenciamento-de-sessao/) 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](/glossary/pt/oauth-2-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.