Como Adicionar Login ao Seu App: Senhas, Links Mágicos, Google e Papéis

Para adicionar login a um app, escolha um método — e-mail e senha, links mágicos (um link de acesso único enviado por e-mail) ou “Entrar com o Google” — e implemente-o com uma biblioteca de autenticação comprovada ou com um provedor hospedado, em vez de fazer do zero. Depois, defina o que cada tipo de usuário pode fazer (papéis) e aplique isso no servidor em cada página e requisição de API. As sessões devem usar cookies seguros, expirar e terminar corretamente no logout.

Este guia percorre cada escolha e os detalhes que separam um login que funciona de um login seguro. Para os conceitos por trás disso, veja o que é autenticação.

Decida primeiro: você precisa mesmo de login?

O login adiciona atrito e responsabilidade. Você precisa dele quando:

• Os usuários têm dados privados (suas reservas, documentos, faturas)
• Os usuários podem alterar coisas que outros vão ver
• Você cobra pelo acesso
• Pessoas diferentes precisam de permissões diferentes (dono, equipe, cliente)

Você pode não precisar dele em um site de marketing, em um diretório público ou em um formulário que apenas envia um e-mail para você. Uma lista de espera não precisa de contas; um campo de e-mail basta.

Os quatro métodos de login mais comuns

Muitos apps combinam dois métodos: o login com Google mais links mágicos por e-mail é uma combinação popular que cobre a maioria das pessoas sem armazenar nenhuma senha.

E-mail e senha

Se você oferece senhas, estes pontos são obrigatórios:

• Use um algoritmo lento de hash de senhas. O guia de armazenamento de senhas da OWASP recomenda Argon2id, com scrypt, bcrypt ou PBKDF2 como alternativas. Nunca guarde senhas em texto puro nem com um hash rápido de uso geral.
• As redefinições de senha usam um link aleatório, de uso único e com validade, enviado para o e-mail verificado.
• Não revele quais e-mails têm conta. “Se esse e-mail estiver cadastrado, enviamos um link de redefinição” é melhor do que “Nenhuma conta encontrada”.
• Limite a taxa de tentativas de login e de redefinição para dificultar a adivinhação de senhas.
• Permita senhas longas e gerenciadores de senha; dispense regras que obriguem combinações estranhas de caracteres.

Links mágicos e códigos de uso único

Um link mágico é um link de acesso enviado por e-mail ao usuário. Ao clicar, ele entra no app. Um código de uso único é a mesma ideia, digitado em vez de clicado.

• Links e códigos expiram rapidamente e funcionam apenas uma vez.
• O link deve logar o usuário no dispositivo onde ele clicou, e o token não pode ficar em logs nem em ferramentas de analytics.
• Você precisa de envio de e-mail confiável — veja como enviar e-mails do seu app. Teste com Gmail e Outlook e confira a caixa de spam.

Entrar com o Google (e outros provedores OAuth)

“Entrar com o Google” usa OAuth e OpenID Connect: o Google confirma quem é o usuário e informa ao seu app o e-mail e o nome dele. A configuração, a partir de setembro de 2026, acontece na seção Google Auth Platform do Google Cloud Console:

1. Crie ou selecione um projeto e preencha a página Branding — o que os usuários veem na tela de consentimento (nome do app, e-mail de suporte, logo).
2. Na página Clients, crie um cliente do tipo “Aplicativo da Web”.
3. Adicione suas origens JavaScript autorizadas e URIs de redirecionamento — os endereços exatos onde o seu app roda e para onde o Google devolve o usuário após o login.
4. Guarde o ID do cliente e o segredo do cliente nos segredos do seu app.

Coisas que costumam dar errado, segundo a documentação OAuth do Google:

• redirect_uri_mismatch: o endereço de redirecionamento precisa coincidir exatamente, incluindo http versus https, maiúsculas e minúsculas e qualquer barra final. Adicione um para o seu endereço de preview e outro para o seu domínio publicado.
• HTTPS obrigatório: URIs de redirecionamento devem usar HTTPS, exceto localhost durante o desenvolvimento.
• O parâmetro state deve ser verificado no retorno para proteger contra falsificação de requisição entre sites (CSRF). Boas bibliotecas fazem isso por você.

Se você pedir apenas informações básicas de login (nome, e-mail, perfil), o Google diz que a verificação do app não é obrigatória. Pedir acesso ao Gmail, ao Drive ou à Agenda dos usuários é diferente e exige verificação.

Construir ou usar um provedor?

As duas primeiras são razoáveis. Provedores hospedados fazem mais por você, mas adicionam uma dependência e às vezes cobram por usuário ativo; confira os preços atuais nos sites deles. Bibliotecas mantêm tudo no seu banco de dados, mas deixam mais coisas para você configurar corretamente. Qualquer que seja a escolha, peça à IA para usá-la em vez de criar do zero a lógica de senha ou de sessão.

Papéis e permissões

O login diz quem é a pessoa. As permissões decidem o que ela pode fazer. Mantenha simples no começo:

Regras que importam mais do que os nomes dos papéis:

• Verifique no servidor, sempre. Esconder um botão na página não impede que alguém chame a API diretamente.
• Limite pelo dono. Um membro que busca “agendamento 123” só deve recebê-lo se for dele.
• Usuários não podem se promover. Ignore campos de papel enviados pelo navegador nas atualizações de perfil.
• Padrão é sem acesso. Novas rotas devem exigir login, a menos que você decida o contrário.

Teste com duas contas: entre com uma, anote o ID de um registro, entre com a outra e tente abri-lo. Nossa lista de verificação de segurança tem o teste completo.

Segurança da sessão

Depois do login, o app lembra o usuário com uma sessão — normalmente um cookie. O guia de gerenciamento de sessões da OWASP recomenda:

• Cookies de sessão definidos com Secure (apenas HTTPS), HttpOnly (ilegível por scripts da página) e SameSite
• Um novo ID de sessão emitido no login, e de novo quando os privilégios mudarem
• Um tempo limite por inatividade e uma duração máxima absoluta, aplicados no servidor
• Um logout que encerra a sessão no servidor, e não apenas apaga o cookie
• Sessões invalidadas quando o usuário muda a senha

Guardar tokens de login no local storage do navegador é comum em tutoriais, mas expõe esses tokens a qualquer script rodando na página; cookies seguros costumam ser o padrão melhor para apps web.

Um prompt que cobre o essencial

Adicione contas de usuário a este app. Os usuários podem se cadastrar e entrar com e-mail e senha, ou com o Google. Use [biblioteca ou provedor] em vez de código de autenticação próprio. Faça o hash das senhas com Argon2id ou bcrypt. Adicione a redefinição de senha por e-mail com um link de uso único que expire em uma hora. Mantenha as sessões em cookies seguros, com HttpOnly. Proteja /dashboard e todas as rotas /api para que apenas usuários logados as usem, e garanta que os usuários só vejam os próprios projetos. Adicione um papel “admin” que pode ver todos os usuários; apenas administradores podem acessar /admin, verificado no servidor.

Depois, teste: cadastre-se, saia, entre de novo, redefina a senha, tente acessar uma URL privada sem estar logado e tente acessar um registro de outro usuário.

Erros comuns no login criado com IA

• Proteção apenas na página. A página redireciona usuários não logados, mas a API devolve dados para qualquer um.
• Segredos no navegador. Segredos de cliente OAuth e chaves administrativas do provedor de autenticação pertencem ao servidor.
• URLs de preview e publicada misturadas. O URI de redirecionamento do Google ou o link do e-mail de redefinição aponta para o preview, e o login quebra após a publicação.
• Nenhuma verificação de e-mail. Qualquer um pode se cadastrar como anyone@empresa.com. Verifique o e-mail antes de conceder algo ligado àquele endereço.
• Testar apenas o caminho feliz. Tente senhas erradas, links expirados e uma segunda conta.

Adicionando login no Mythex

No Mythex, o login dos usuários do seu app é algo que você adiciona ao seu app — é separado da sua própria conta no Mythex. O Mythex não oferece um produto de autenticação embutido, então você traz uma biblioteca ou provedor de autenticação e as chaves dele:

1. Escolha uma abordagem — por exemplo, e-mail e senha guardados no seu próprio banco de dados, ou o SDK de um provedor hospedado.
2. Se você guarda os usuários por conta própria, o app precisa de um banco de dados; peça um no chat ou use /database.
3. Coloque as chaves do provedor nos segredos do projeto (/secrets ou nas configurações do projeto).
4. Use um prompt como o acima e teste no Preview. Para o login com Google, adicione URIs de redirecionamento para o seu endereço de preview e para o endereço publicado.

Veja Adicionar login ao seu app na documentação. Se você está construindo um produto pago, como criar um MVP de SaaS cobre contas e cobrança juntas.

Perguntas