Autenticação e Autorização

A autenticação estabelece a identidade. O sistema verifica se um usuário é quem afirma ser — normalmente por meio de credenciais como senha, token ou provedor externo de identidade.

A autorização acontece depois que a identidade é confirmada. O sistema avalia se essa identidade tem permissão para executar uma ação específica ou acessar um recurso particular.

Essas preocupações devem permanecer separadas. A verificação de identidade não implica automaticamente direitos de acesso. Um usuário autenticado ainda pode não ter permissão para visualizar certos dados ou executar ações administrativas.

Em termos conceituais: Usuário → Login → Identidade Verificada → Checagem de Permissão → Acesso ao Recurso.

A autenticação acontece primeiro. A autorização acontece depois — muitas vezes em cada requisição.

A autenticação começa quando um usuário ou sistema declara uma identidade e apresenta credenciais como prova.

Nome de usuário + senha é o método tradicional. O servidor verifica as credenciais enviadas em relação aos dados da conta armazenados.

Login OAuth delega a autenticação a um provedor externo confiável (como Google ou GitHub), que retorna uma identidade verificada para a aplicação.

Chaves de API são comumente usadas para autenticação entre servidores, identificando aplicações em vez de usuários humanos.

Autenticação multifator (MFA) fortalece a verificação de identidade ao exigir uma segunda prova (como um código de uso único ou um token de hardware).

Fluxo conceitual: Login → Credenciais Enviadas → Servidor Verifica → Identidade Confirmada.

Sem uma identidade válida, a solicitação para aqui.

Em aplicações web tradicionais, a autenticação é tratada usando sessões no lado do servidor.

Quando um usuário faz login com sucesso, o servidor gera um objeto de sessão contendo informações de identidade. Essa sessão é armazenada no servidor — normalmente na memória, em um banco de dados ou em um cache distribuído.

O servidor envia um session ID de volta ao cliente, normalmente armazenado em um cookie. Em requisições subsequentes, o navegador inclui esse cookie automaticamente.

O servidor lê o session ID, recupera os dados da sessão correspondentes e determina a identidade do usuário.

A ideia principal é simples: o servidor armazena o estado da sessão. O cliente armazena apenas uma referência a ele.

Em APIs modernas e sistemas distribuídos, a autenticação costuma ser sem estado.

Após um login bem-sucedido, o servidor gera um token assinado contendo informações de identidade. Esse token é retornado ao cliente.

Em cada requisição subsequente, o cliente inclui o token — normalmente como um Bearer token no cabeçalho Authorization.

Em vez de buscar os dados da sessão em um armazenamento no lado do servidor, o servidor verifica a assinatura do token e extrai a identidade do usuário diretamente dele.

A principal diferença em relação à autenticação baseada em sessão é que o servidor não mantém o estado da sessão de cada usuário. A verificação da identidade acontece validando o próprio token.

Esse modelo simplifica o escalonamento horizontal porque qualquer instância do servidor pode validar o token sem armazenamento compartilhado de sessão.

Um JWT é uma string estruturada composta por três seções codificadas em Base64 e separadas por pontos:

Header → metadados sobre o token e o algoritmo de assinatura
Payload → claims (como ID do usuário ou função)
Signature → prova criptográfica de que o token não foi alterado

Quando um servidor emite um JWT, ele assina o token usando uma chave secreta ou chave privada. Quando o token é apresentado posteriormente, o servidor verifica a assinatura para garantir que o payload não foi modificado.

Esclarecimento importante: JWTs não são criptografados por padrão. O payload pode ser decodificado por qualquer pessoa que tenha o token. A assinatura apenas garante integridade, não confidencialidade.

JWTs são úteis porque permitem que informações de identidade acompanhem a requisição de forma verificável, sem exigir armazenamento de sessão no lado do servidor.

Depois que a identidade de um usuário é confirmada, o sistema precisa decidir quais ações ele pode executar.

A autorização aplica regras de controle de acesso. Mesmo que um usuário esteja autenticado, ele pode não ter permissão para acessar certos recursos ou executar determinadas operações.

Um modelo comum é Role-Based Access Control (RBAC), no qual os usuários recebem funções como “admin”, “editor” ou “viewer”, e cada função tem permissões predefinidas.

Outro modelo é Attribute-Based Access Control (ABAC), no qual as decisões são tomadas com base em atributos como propriedades do usuário, propriedades do recurso ou contexto da requisição.

A autenticação normalmente acontece uma vez por sessão ou emissão de token. Já a autorização é avaliada em toda requisição protegida para garantir que as regras de acesso sejam aplicadas de forma consistente.

Quando uma requisição chega ao servidor, ela não executa imediatamente a lógica da aplicação. Primeiro, ela passa por uma camada de autenticação, geralmente implementada como middleware em frameworks como Express, Django ou FastAPI.

Esse middleware verifica credenciais como um cookie de sessão ou um token de autorização. Se as credenciais estiverem ausentes ou inválidas, o servidor rejeita a requisição com uma resposta 401 Unauthorized.

Se a identidade for verificada com sucesso, o sistema então avalia as permissões. Quando o usuário não tem acesso ao recurso solicitado, o servidor retorna 403 Forbidden.

Somente depois que as verificações de autenticação e autorização passam é que a requisição chega ao handler e executa a lógica de negócio, garantindo que operações sensíveis estejam protegidas contra acesso não autorizado.

Mesmo um fluxo de autenticação implementado corretamente pode ser inseguro se as proteções principais estiverem ausentes.

As senhas devem ser hashadas antes de serem armazenadas em um banco de dados. O hashing garante que, mesmo que o banco de dados seja comprometido, as senhas em texto puro não sejam expostas.

Todo o tráfego de autenticação deve ser transmitido por HTTPS. Sem criptografia em trânsito, credenciais e tokens podem ser interceptados por atacantes.

Os access tokens devem ter tempos de expiração. Tokens de curta duração reduzem o dano se um token for roubado. Muitos sistemas usam refresh tokens para obter novos access tokens sem exigir que os usuários façam login repetidamente.

Segurança não é apenas verificar identidade — é proteger os mecanismos que verificam a identidade.