Autenticação vs autorização: o que muda entre fazer login e ter permissões
Publicado em 2026-10-20 por frfrand
Autenticación confirma quién sos y autorización decide a qué podés acceder: ejemplos, fallos y formas de probar permisos.
Autenticação é comprovar quem está tentando acessar um aplicativo. Autorização é decidir o que essa identidade pode fazer. São duas perguntas diferentes e confundí-las causa erros graves de segurança.
Quando você faz login em um painel e digita sua senha, o sistema tenta reconhecer sua identidade. Uma vez dentro, decidir se você pode consultar a faturação de outro cliente é um problema distinto.
O exemplo do edifício
Imagine uma empresa com recepção e vários escritórios. Para entrar, você mostra seu crachá de funcionário: isso identifica quem você é. Mas o crachá não deveria abrir automaticamente o gabinete da direção, o armazém e todos os arquivos confidenciais.
A autorização estabelece essas restrições. Uma pessoa pode fazer login corretamente e, mesmo assim, receber um erro ao tentar acessar uma função para a qual não tem permissão.
Quais mecanismos servem para autenticar?
Uma senha, uma chave de segurança, uma sessão válida ou um sistema de login externo podem participar do processo. Também existem formas de combinar fatores para dificultar o roubo de contas.
Nenhum método é perfeito. Uma sessão pode ser roubada, uma senha reutilizada pode vazar e uma integração mal configurada pode aceitar identidades que não deveria.
Por isso importa também como as sessões são revogadas e como acessos anômalos são detectados.
Como a autorização é aplicada?
Um app pode utilizar papéis como leitor, editor ou administrador. Mas em aplicações multilocação não basta verificar o papel: é preciso validar a qual organização ou recurso concreto o dado pertence.
Por exemplo, alguém pode ser administrador da empresa A e não ter nenhum acesso à empresa B. Um endpoint que verifica apenas role=admin e esquece de checar a empresa pode expor informações de outros clientes.
O controle tem que ser executado do lado do servidor, não apenas ocultando botões no frontend.
Um caso típico: mudar um ID na URL
Imaginemos que uma API permite consultar uma fatura através de /faturas/123. Uma pessoa faz login legítimamente e altera o número para 124.
Se o backend devolver uma fatura de outra conta sem verificar o proprietário, existe um problema de autorização. É o tipo de erro que pode ocorrer mesmo que a autenticação funcione perfeitamente.
A solução consiste em aplicar permissões em cada operação e recurso sensível, e testar tanto casos permitidos quanto proibidos.
E o que acontece com um token válido?
Um token pode ajudar a identificar uma pessoa ou cliente, mas válido não significa autorizado para tudo. É preciso verificar seu escopo, expiração, audiência e as permissões reais da operação.
A autorização também pode mudar durante uma sessão: alguém perde o acesso a um projeto e o sistema precisa deixar de permitir ações que antes eram legítimas.
Como testar antes de publicar
Prepare usuários com diferentes papéis e organizações. Tente acessar os recursos que pertencem a eles e depois os que não pertencem. Verifique se o servidor responde corretamente, sem vazar dados privados.
Não fique apenas no teste de «o administrador pode abrir o painel». É igualmente importante verificar que um leitor não pode excluir registros e que um usuário de uma empresa não pode consultar outra.
Onde entra o ArduMaker?
O ArduMaker organiza projetos e recursos por empresas e equipes. O princípio é o mesmo: reconhecer uma conta não basta; cada operação sobre um VPS, aplicativo ou dado deve respeitar as permissões e o escopo empresarial correspondente.
Em resumo: autenticação responde «quem você é?». Autorização responde «você pode fazer isso?». Um aplicativo precisa dos dois e deve verificar o segundo em cada acesso sensível.
Fontes: OWASP Authorization Cheat Sheet · OWASP Authentication Cheat Sheet.