Como Adicionar Login à Sua App: Palavras-passe, Links Mágicos, Google e Perfis

Para adicionar login a uma app, escolha um método — email e palavra-passe, links mágicos (um link de início de sessão de utilização única enviado por email) ou «Iniciar sessão com o Google» — e implemente-o com uma biblioteca de autenticação comprovada ou com um fornecedor alojado, em vez de o fazer do zero. Depois, decida o que cada tipo de utilizador pode fazer (perfis) e aplique isso no servidor em cada página e pedido à API. As sessões devem usar cookies seguros, expirar e terminar corretamente ao sair.

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

Decida primeiro: precisa mesmo de login?

O login acrescenta atrito e responsabilidade. Precisa dele quando:

• Os utilizadores têm dados privados (as suas marcações, documentos, faturas)
• Os utilizadores podem alterar coisas que outros vão ver
• Cobra pelo acesso
• Pessoas diferentes precisam de permissões diferentes (proprietário vs colaborador vs cliente)

Pode não precisar dele para um site de marketing, um diretório público ou um formulário que apenas lhe envia um email. Uma lista de espera não precisa de contas; um campo de email chega.

Os quatro métodos de login mais comuns

Muitas apps combinam dois: o login Google mais links mágicos por email é uma combinação popular que cobre a maioria das pessoas sem guardar palavras-passe.

Email e palavra-passe

Se oferecer palavras-passe, estes são os requisitos essenciais:

• Faça o hash das palavras-passe com um algoritmo de hashing lento. As orientações da OWASP sobre armazenamento de palavras-passe recomendam Argon2id, com scrypt, bcrypt ou PBKDF2 como alternativas. Nunca guarde palavras-passe em texto simples nem com um hash geral rápido.
• As recuperações de palavra-passe usam um link aleatório, de utilização única e com validade, enviado para o email verificado.
• Não revele que emails têm conta. «Se esse email estiver registado, enviámos um link de recuperação» é melhor do que «Conta não encontrada».
• Limite as tentativas de início de sessão e de recuperação para abrandar a adivinhação de palavras-passe.
• Permita palavras-passe longas e gestores de palavras-passe; dispense regras que obrigam a combinações estranhas de caracteres.

Links mágicos e códigos de utilização única

Um link mágico é um link de início de sessão enviado por email ao utilizador. Ao clicar, o utilizador entra. Um código de utilização única é a mesma ideia, mas digitado em vez de clicado.

• Os links e códigos expiram rapidamente e funcionam apenas uma vez.
• O link deve iniciar sessão no dispositivo onde foi clicado, e o token não pode ficar em registos nem em ferramentas de analytics.
• Precisa de um envio de emails fiável — veja como enviar emails a partir da sua app. Teste com Gmail e Outlook, e verifique a pasta de spam.

Iniciar sessão com o Google (e outros fornecedores OAuth)

«Iniciar sessão com o Google» usa OAuth e OpenID Connect: a Google confirma quem é o utilizador e diz à sua app o email e o nome dele. A configuração, a partir de setembro de 2026, faz-se na secção Google Auth Platform da Google Cloud Console:

1. Crie ou selecione um projeto e preencha a página Branding — o que os utilizadores veem no ecrã de consentimento (nome da app, email de suporte, logótipo).
2. Na página Clients, crie um cliente do tipo «Web application».
3. Adicione as suas authorized JavaScript origins e os redirect URIs — os endereços exatos onde a sua app corre e para onde a Google devolve o utilizador depois do início de sessão.
4. Guarde o client ID e o client secret nos segredos da sua app.

Coisas que costumam correr mal, segundo a documentação OAuth da Google:

• redirect_uri_mismatch: o endereço de redirecionamento tem de corresponder exatamente, incluindo http vs 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 em produção.
• HTTPS obrigatório: os redirect URIs têm de usar HTTPS, exceto localhost durante o desenvolvimento.
• O parâmetro state deve ser verificado no regresso, para proteger contra falsificação de pedidos entre sites. As boas bibliotecas fazem isto por si.

Se pedir apenas informação básica de início de sessão (nome, email, perfil), a Google diz que a verificação da app não é obrigatória. Pedir acesso ao Gmail, Drive ou Calendar dos utilizadores é diferente e exige verificação.

Construir ou usar um fornecedor?

As duas primeiras são razoáveis. Os fornecedores alojados tratam de mais coisas, mas acrescentam uma dependência e por vezes cobram por utilizador ativo; confirme os preços atuais nos sites deles. As bibliotecas mantêm tudo na sua base de dados, mas deixam-lhe mais para configurar corretamente. Qualquer que escolha, peça à IA que use a solução em vez de criar lógica de palavras-passe ou de sessões à mão.

Perfis e permissões

O login diz-lhe quem é alguém. As permissões decidem o que essa pessoa pode fazer. Mantenha simples no início:

Regras que importam mais do que os nomes dos perfis:

• Verifique no servidor, sempre. Esconder um botão na página não impede ninguém de chamar a API diretamente.
• Limite pelo proprietário. Um membro que pede «marcação 123» só a deve receber se for dele.
• Os utilizadores não se podem promover a si próprios. Ignore campos de perfil enviados pelo browser ao atualizar o perfil.
• Por defeito, sem acesso. Novas rotas devem exigir início de sessão, a não ser que decida o contrário.

Teste com duas contas: inicie sessão com uma, anote o ID de um registo, inicie sessão com a outra e tente abri-lo. A nossa lista de segurança tem o teste completo.

Segurança da sessão

Depois do login, a app lembra o utilizador através de uma sessão — normalmente um cookie. As orientações da OWASP sobre gestão de sessões recomendam:

• Cookies de sessão definidos com Secure (apenas HTTPS), HttpOnly (ilegíveis por scripts da página) e SameSite
• Um novo ID de sessão emitido no início de sessão, e de novo quando os privilégios mudam
• Um tempo limite por inatividade e uma duração máxima absoluta, aplicados no servidor
• Um terminar de sessão que encerra a sessão no servidor, e não apenas apaga o cookie
• Sessões invalidadas quando o utilizador altera a palavra-passe

Guardar tokens de login no armazenamento local do browser é comum em tutoriais, mas expõe-nos a qualquer script a correr na página; os cookies seguros são normalmente a melhor opção por defeito para apps web.

Um prompt que cobre o essencial

Adicione contas de utilizador a esta app. Os utilizadores podem registar-se e iniciar sessão com email e palavra-passe, ou com o Google. Use [biblioteca ou fornecedor] em vez de código de autenticação próprio. Faça o hash das palavras-passe com Argon2id ou bcrypt. Adicione recuperação de palavra-passe por email com um link de utilização única que expire em uma hora. Guarde as sessões em cookies seguros e HttpOnly. Proteja /dashboard e cada rota /api para que só utilizadores com sessão iniciada as possam usar, e garanta que os utilizadores só veem os seus próprios projetos. Adicione um perfil «admin» que possa ver todos os utilizadores; só os administradores podem aceder a /admin, verificado no servidor.

Depois teste: registe-se, saia, volte a entrar, recupere a palavra-passe, tente um URL privado sem sessão iniciada e tente aceder ao registo de outro utilizador.

Erros comuns no login criado com IA

• Proteção só na página. A página redireciona utilizadores sem sessão, mas a API devolve dados a qualquer pessoa.
• Segredos no browser. Os client secrets OAuth e as chaves de administração do fornecedor de autenticação pertencem ao servidor.
• URLs de Preview e de produção trocados. O redirect URI da Google ou a ligação do email de recuperação aponta para o Preview, e o login deixa de funcionar depois de publicar.
• Sem verificação de email. Qualquer pessoa pode registar-se como alguem@empresa.com. Verifique o email antes de conceder algo ligado a esse endereço.
• Testar apenas o caminho feliz. Experimente palavras-passe erradas, links expirados e uma segunda conta.

Adicionar login na Mythex

Na Mythex, o login para os utilizadores da sua app é algo que acrescenta à sua app — é separado da sua própria conta Mythex. A Mythex não oferece um produto de autenticação integrado, por isso traz uma biblioteca ou fornecedor de autenticação e as respetivas chaves:

1. Escolha uma abordagem — por exemplo, email e palavra-passe guardados na sua base de dados, ou o SDK de um fornecedor alojado.
2. Se guardar os utilizadores você mesmo, a app precisa de uma base de dados; peça-a no chat ou use /database.
3. Coloque as chaves do fornecedor nos segredos do projeto (/secrets ou nas definições do projeto).
4. Use um prompt como o de cima e teste no Preview. Para o login Google, adicione redirect URIs tanto para o seu Preview como para o endereço publicado.

Veja Adicionar login à sua app na documentação. Se estiver a construir um produto pago, como construir um MVP de SaaS aborda contas e faturação em conjunto.

Perguntas