O que é autenticação? Logins, sessões e OAuth explicados

Autenticação é como um app confirma quem é o usuário — normalmente verificando algo que a pessoa sabe (uma senha), algo que ela tem (um código enviado ao celular ou ao e-mail) ou uma identidade de outro serviço confiável (como "Entrar com o Google"). Depois que o usuário é autenticado, o app o reconhece com uma sessão ou um token, para que ele não precise fazer login em cada página. Decidir o que esse usuário conhecido pode fazer é uma etapa separada, chamada autorização.

Por que isso importa quando você cria com IA

Adicionar login é um dos pedidos mais comuns feitos a um criador de apps com IA, e um dos mais fáceis de errar de forma sutil. Uma página de login é simples de gerar. A parte difícil é tudo o que está ao redor:

• As senhas estão armazenadas com segurança?
• Toda página privada e todo endpoint da API realmente verifica quem está pedindo?
• Um cliente logado consegue ver os dados de outro cliente apenas trocando um número na URL?
• O que acontece quando alguém esquece a senha?

Um app pode parecer perfeitamente seguro e falhar em todos esses pontos. Entender as partes móveis permite fazer as perguntas certas e testar as coisas certas.

Uma analogia do dia a dia

Pense em fazer check-in em um hotel.

Na recepção você mostra um documento. Isso é autenticação: provar quem você é. A recepcionista então entrega um cartão de acesso. Esse cartão é a sua sessão: pelo resto da estadia você não precisa mostrar o documento de novo; basta aproximar o cartão.

O cartão abre o seu quarto, a academia e o elevador até o seu andar — mas não os quartos de outros hóspedes nem a sala da equipe. Isso é autorização: aquilo a que a sua identidade tem permissão de acessar. Se você perder o cartão, o hotel pode desativá-lo na recepção (revogar a sessão). Quando você faz o check-out, ele deixa de funcionar (logout ou expiração).

"Entrar com o Google" é como um hotel aceitar uma carta de um parceiro de confiança dizendo "esta é a pessoa", em vez de conferir o seu documento por conta própria.

Os principais métodos de login

Como as senhas devem ser armazenadas

Um app seguro nunca guarda a sua senha real. Em vez disso, guarda um hash: o resultado de uma função unidirecional que transforma a senha em uma sequência fixa. Quando você faz login, o app aplica o hash ao que você digitou e compara o resultado com o hash guardado.

Dois detalhes tornam isso seguro:

• Um salt — um valor aleatório acrescentado a cada senha antes do hash, de modo que duas pessoas com a mesma senha recebam hashes diferentes, e tabelas de consulta pré-calculadas deixam de servir.
• Um algoritmo lento feito para senhas — como Argon2, bcrypt ou scrypt. Hashes de uso geral, como MD5 ou SHA-256, são rápidos demais por conta própria; atacantes conseguem testar bilhões de palpites.

Hash não é o mesmo que criptografia. Dados criptografados podem ser descriptografados com uma chave; um hash de senha é projetado para não ser reversível de forma alguma.

Sessões vs tokens

Depois do login, o app precisa reconhecer você em cada requisição. Existem duas abordagens comuns.

Para cookies, três configurações importam: HttpOnly (o JavaScript da página não consegue ler o cookie), Secure (enviado somente por HTTPS) e SameSite (limita o envio em requisições vindas de outros sites). Guardar tokens no localStorage do navegador é comum, mas os expõe a qualquer script que rode na página.

OAuth e "Entrar com o Google"

OAuth 2.0 é um padrão para autorização delegada: ele permite que um app obtenha acesso limitado à sua conta em outro serviço — por exemplo, ler a sua agenda do Google — sem nunca ver a sua senha do Google. Você é enviado ao Google, aprova permissões específicas (chamadas escopos), e o Google dá ao app um token apenas para essas permissões.

O OAuth, sozinho, foi projetado para conceder acesso, não para dizer quem você é. O OpenID Connect (OIDC) é uma camada sobre o OAuth 2.0 que acrescenta identidade, e é isso que o "Entrar com o Google" ou "Entrar com a Apple" usa. Para configurar, você registra seu app no provedor e obtém um client ID e um client secret; o secret fica no seu servidor.

Um exemplo prático: login para um portal de clientes

Suponha que você está criando um portal onde os clientes de uma agência de design veem seus projetos e faturas.

• Autenticação: os clientes entram com e-mail e um link mágico, então não há senhas para gerenciar. A equipe da agência entra com contas do Google Workspace.
• Papéis: cada usuário tem um papel — client ou staff.
• Regras de autorização:

• Onde é aplicado: no servidor, em cada requisição. O servidor busca o usuário logado e só devolve os projetos em que project.company_id corresponde à empresa do usuário. Esconder o botão "Marcar como paga" não basta — o endpoint em si precisa recusar.

Termos comuns explicados

Erros comuns e equívocos

• Verificar permissões apenas na página. Se o navegador esconde um botão mas a API não verifica, qualquer pessoa pode chamar a API diretamente.
• Confiar em IDs vindos da URL. /invoices/1042 precisa verificar que a fatura 1042 pertence ao usuário logado.
• Criar a própria criptografia. Use bibliotecas ou provedores conhecidos; não deixe a IA inventar um esquema de hash.
• Redefinição de senha fraca. Os links de redefinição devem ser de uso único, expirar rapidamente e não revelar se um e-mail tem conta.
• Confundir o seu login com o do criador da ferramenta. Os usuários do seu app são separados da sua conta na ferramenta com que você constrói.
• Nenhum limite de tentativas no login. Sem ele, atacantes podem testar senhas sem parar.

O que pedir ao seu criador de apps com IA

• "Adicione cadastro e login usando [uma biblioteca ou provedor conhecido]. Não escreva hash de senha personalizado."
• "Armazene as senhas com hash usando bcrypt ou Argon2."
• "Use cookies HttpOnly e Secure para a sessão."
• "Adicione papéis: admin e member. Liste cada endpoint e quais papéis podem chamá-lo."
• "Garanta no servidor que os usuários só leiam e editem os próprios registros. Depois me mostre como você verificou."
• "Adicione redefinição de senha com links de uso único que expirem em uma hora."
• "Limite a taxa de tentativas de login."

Depois, teste você mesmo: crie duas contas e tente acessar os dados de uma delas estando logado com a outra. Nosso guia para adicionar login e nosso checklist de segurança vão além.

Autenticação no Mythex

O Mythex não oferece um produto de autenticação embutido para os usuários do seu app; você escolhe a abordagem — e-mail e senha guardados no banco de dados do seu projeto, ou o SDK de um provedor hospedado — e pede ao agente para adicioná-la. As chaves do provedor vão para os segredos do projeto, não para o chat. Isso é separado de como você entra no próprio Mythex. A receita da documentação sobre como adicionar login ao seu app tem um prompt inicial que você pode adaptar, e o que é uma API explica onde ficam essas verificações feitas no servidor.

Perguntas