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

A autenticação é a forma como uma app confirma quem é o utilizador — normalmente verificando algo que a pessoa sabe (uma password), algo que tem (um código enviado para o telemóvel ou email) ou uma identidade de outro serviço de confiança (como o «Iniciar sessão com Google»). Depois de autenticado, a app lembra-se do utilizador com uma sessão ou token, para que ele não tenha de iniciar sessão em cada página. Decidir o que esse utilizador conhecido pode fazer é um passo separado, chamado autorização.

Porque é que importa quando cria com IA

Acrescentar login é um dos pedidos mais comuns a um criador com IA, e um dos mais fáceis de fazer mal de forma subtil. Uma página de login é simples de gerar. A parte difícil é tudo o que a rodeia:

As passwords estão guardadas de forma segura?
Cada página privada e cada endpoint da API verifica mesmo quem está a pedir?
Um cliente com sessão iniciada consegue ver os dados de outro cliente só mudando um número no URL?
O que acontece quando alguém se esquece da password?

Uma app pode parecer perfeitamente segura e falhar em todos estes pontos. Perceber as peças em movimento permite-lhe fazer as perguntas certas e testar as coisas certas.

Uma analogia do dia a dia

Pense em fazer o check-in num hotel.

Na receção mostra o documento de identificação. Isso é autenticação: provar quem é. A rececionista entrega-lhe depois um cartão de acesso. Esse cartão é a sua sessão: durante toda a estadia não volta a mostrar o documento; basta encostar o cartão.

O cartão abre o seu quarto, o ginásio e o elevador do seu piso — mas não os quartos de outros hóspedes nem o gabinete do pessoal. Isso é autorização: a que partes a sua identidade tem acesso. Se perder o cartão, o hotel pode desativá-lo na receção (revogar a sessão). Quando faz o check-out, deixa de funcionar (terminar sessão, ou expiração).

«Iniciar sessão com Google» é como um hotel que aceita uma carta de um parceiro de confiança a dizer «esta pessoa é quem diz ser», em vez de verificar o seu documento.

Método	Como funciona	Vantagens	Desvantagens
Email + password	O utilizador escolhe uma password; a app guarda um hash dela	Familiar, sem dependências externas	Tem de guardar os hashes com segurança e tratar das recuperações
Link mágico / código de uso único	A app envia por email um link ou código que inicia sessão	Sem passwords para roubar ou esquecer	Depende da entrega de email; login mais lento
Login social (OAuth / OpenID Connect)	O utilizador entra com Google, Apple, GitHub, etc.	Rápido para o utilizador; não guarda passwords	Configuração em cada fornecedor; utilizadores sem essas contas
Fornecedor de autenticação alojado	Um serviço como Clerk, Auth0 ou Supabase Auth trata do registo, login e recuperações	Menos trabalho de segurança para si	Custo mensal à escala; mais uma dependência
Autenticação de dois fatores (MFA / 2FA)	Uma segunda verificação após a primeira, como um código de app autenticadora	Muito mais difícil de invadir	Um pouco mais de fricção

Como as passwords devem ser guardadas

Uma app segura nunca guarda a sua password real. Guarda um hash: o resultado de uma função de sentido único que transforma a password numa cadeia fixa. Quando inicia sessão, a app faz o hash do que escreveu e compara o resultado com o hash guardado.

Dois detalhes tornam isto seguro:

Um sal — um valor aleatório acrescentado a cada password antes do hash, para que duas pessoas com a mesma password tenham hashes diferentes e as tabelas de pesquisa pré-calculadas deixem de servir.
Um algoritmo lento feito para passwords — como o Argon2, o bcrypt ou o scrypt. Hashes de uso geral, como MD5 ou SHA-256, são demasiado rápidos por si; os atacantes conseguem testar milhares de milhões de palpites.

Hash não é o mesmo que cifra. Dados cifrados podem ser decifrados com uma chave; um hash de password é concebido para não ser reversível.

Sessões vs tokens

Depois do login, a app precisa de o reconhecer em cada pedido. Há duas abordagens comuns.

	Sessão (cookie)	Token (ex.: JWT)
O que o navegador guarda	Um ID de sessão aleatório num cookie	Um token assinado com informação do utilizador e uma data de validade
Onde vive o estado de login	No servidor, numa base de dados ou armazenamento	Dentro do próprio token
Terminar a sessão em todo o lado	Fácil: apagar a sessão no servidor	Mais difícil: o token continua válido até expirar, a menos que mantenha uma lista de bloqueio
Uso típico	Aplicações web tradicionais	APIs, apps móveis, serviços que comunicam entre si

Nos cookies, três definições são importantes: HttpOnly (o JavaScript da página não consegue ler o cookie), Secure (enviado apenas por HTTPS) e SameSite (limita o envio em pedidos vindos de outros sites). Guardar tokens no localStorage do navegador é comum, mas expõe-nos a qualquer script que corra na página.

OAuth e «Iniciar sessão com Google»

O OAuth 2.0 é uma norma para autorização delegada: permite a uma app obter acesso limitado à sua conta noutro serviço — por exemplo, ler o seu Google Calendar — sem nunca ver a sua password da Google. É enviado para a Google, aprova permissões específicas (chamadas scopes), e a Google dá à app um token só para essas permissões.

O OAuth, por si, foi concebido para conceder acesso, não para dizer quem é a pessoa. O OpenID Connect (OIDC) é uma camada por cima do OAuth 2.0 que acrescenta identidade, e é isso que o «Iniciar sessão com Google» ou o «Iniciar sessão com Apple» usam. Para o configurar, regista a sua app no fornecedor e obtém um client ID e um client secret; o secret fica no seu servidor.

Imagine que está a criar um portal onde os clientes de uma agência de design veem os seus projetos e faturas.

Autenticação: os clientes entram com email e um link mágico, por isso não há passwords para gerir. A equipa da agência entra com contas Google Workspace.
Perfis: cada utilizador tem um perfil — cliente ou equipa.
Regras de autorização:

Ação	Cliente	Equipa
Ver os projetos da própria empresa	Sim	Sim
Ver projetos de outras empresas	Não	Sim
Carregar um ficheiro para um projeto	Só nos próprios projetos	Sim
Marcar uma fatura como paga	Não	Sim

Onde é aplicado: no servidor, em cada pedido. O servidor procura o utilizador com sessão iniciada e só devolve os projetos em que project.company_id corresponde à empresa do utilizador. Esconder o botão «Marcar como paga» não basta — o endpoint tem de recusar por si.

Termos comuns explicados

Termo	Significado
Autenticação (AuthN)	Confirmar quem é alguém.
Autorização (AuthZ)	Decidir o que essa pessoa pode fazer.
Sessão	A app lembrar-se de que tem sessão iniciada, entre pedidos.
Cookie	Um pequeno pedaço de dados que o navegador devolve ao site em cada pedido.
JWT	JSON Web Token: um token assinado e compacto que transporta dados como o ID do utilizador e a validade.
Perfil / permissão	Rótulos como `admin` ou `membro` que decidem o acesso.
MFA / 2FA	Exigir uma segunda prova, como um código de uma app autenticadora.
SSO	Single sign-on: um único login (muitas vezes uma conta de empresa) para muitas apps.
401 vs 403	«Quem é você?» (não autenticado) vs «Não pode fazer isso» (não autorizado).

Erros e ideias erradas comuns

Verificar permissões só 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 que vêm do URL. /invoices/1042 tem de verificar que a fatura 1042 pertence ao utilizador com sessão iniciada.
Criar a sua própria criptografia. Use bibliotecas conhecidas ou fornecedores; não deixe a IA inventar um esquema de hash.
Recuperação de password frágil. Os links de recuperação devem ser de uso único, expirar depressa e não revelar se um email tem conta.
Confundir o seu login com o do criador. Os utilizadores da sua app são separados da sua conta na ferramenta com que a constrói.
Sem limite de tentativas no login. Sem isso, os atacantes podem tentar passwords sem fim.

O que pedir ao seu criador com IA

«Acrescenta registo e login com [uma biblioteca ou fornecedor conhecido]. Não escrevas hashing de passwords à medida.»
«Guarda as passwords com hash usando bcrypt ou Argon2.»
«Usa cookies HttpOnly e Secure para a sessão.»
«Acrescenta perfis: admin e membro. Lista cada endpoint e que perfis o podem chamar.»
«Garante no servidor que os utilizadores só leem e editam os próprios registos. Depois mostra-me como verificaste.»
«Acrescenta recuperação de password com links de uso único que expirem numa hora.»
«Limita o número de tentativas de login.»

Depois teste você mesmo: crie duas contas e tente aceder aos dados de uma enquanto tem sessão iniciada na outra. O nosso guia para acrescentar login e a lista de verificação de segurança vão mais longe.

Autenticação no Mythex

O Mythex não oferece um produto de autenticação incorporado para os utilizadores da sua app; escolhe a abordagem — email e password guardados na base de dados do projeto, ou o SDK de um fornecedor alojado — e pede ao agente que a acrescente. As chaves dos fornecedores ficam nos segredos do projeto, não no chat. Isto é separado da forma como inicia sessão no próprio Mythex. A receita da documentação sobre como acrescentar login à sua app tem um prompt inicial que pode adaptar, e o que é uma API explica onde vivem essas verificações do lado do servidor.

Perguntas

Qual é a diferença entre autenticação e autorização?

A autenticação verifica quem é, por exemplo confirmando a password. A autorização decide o que pode fazer depois de ser reconhecido, como se pode ver a página de administração ou editar a marcação de outra pessoa. As apps precisam das duas.

O que é OAuth?

OAuth 2.0 é uma norma que permite a uma app obter acesso limitado à sua conta noutro serviço sem ver a sua password. O «Iniciar sessão com Google» usa o OpenID Connect, uma camada de identidade construída sobre o OAuth 2.0, pelo que a app fica a saber quem é através da Google.

A minha app deve guardar passwords?

Nunca em forma legível. Se usar login com email e password, as passwords têm de ser guardadas como hashes com sal, feitos com um algoritmo lento concebido para passwords, como o Argon2 ou o bcrypt. Muitas apps evitam o problema usando um fornecedor de autenticação alojado, login social ou links mágicos por email.

Sessões ou tokens — qual deve usar a minha app?

Ambos funcionam. Uma sessão guarda o estado de login no servidor e dá ao navegador um ID aleatório num cookie, o que é fácil de revogar. Um token, como um JWT, transporta a própria informação assinada, o que se adapta a APIs e clientes móveis, mas é mais difícil de cancelar antes de expirar. Para uma app web típica, as sessões com cookies são uma boa predefinição.