Autenticação vs autorização: qual a diferença?

"Autenticação" e "autorização" são tão parecidas no nome que viram sinônimos no dia a dia — e essa confusão produz falhas de segurança graves. Uma responde à pergunta quem é você?; a outra, o que você tem permissão de fazer?. Tratar as duas como a mesma coisa é uma das origens mais comuns de acessos indevidos.

Neste artigo você vai entender com clareza a diferença entre os dois conceitos, ver como eles se encaixam em um fluxo de acesso real e conhecer princípios de projeto que evitam os erros clássicos. Ao final, você nunca mais vai trocar um pelo outro.

Duas perguntas diferentes

A distinção fundamental cabe em duas frases:

A ordem importa: primeiro você autentica, depois autoriza. Não faz sentido decidir permissões de alguém cuja identidade você ainda não estabeleceu. Uma analogia útil: a autenticação é mostrar seu documento na portaria de um prédio; a autorização é o crachá que define quais andares e salas você pode abrir.

Repare que as duas etapas são independentes em uma dimensão importante: uma identidade pode estar perfeitamente autenticada e ainda assim não estar autorizada a nada. Um usuário recém-cadastrado é "quem diz ser", mas pode não ter permissão para acessar o painel administrativo. Inversamente, nunca se autoriza algo a uma identidade não verificada. Essa assimetria é a base de todo o raciocínio de controle de acesso.

Essas duas etapas estão no centro de várias categorias do OWASP Top 10 explicado: as 10 maiores falhas de segurança web, tanto em falhas de autenticação quanto em quebra de controle de acesso.

Como funciona a autenticação

Autenticar é provar identidade, e isso se baseia em fatores — categorias de evidência:

Combinar fatores de categorias diferentes é a autenticação multifator (MFA), e é uma das defesas mais eficazes contra contas comprometidas. Uma senha vazada, sozinha, não basta se houver um segundo fator.

Nem todo MFA é igualmente forte. Um código por SMS é melhor que nada, mas é vulnerável a interceptação e a ataques de troca de chip (SIM swap). Um app autenticador gerando códigos TOTP é mais seguro, porque o segredo nunca trafega pela rede. E o padrão mais robusto hoje são as chaves de segurança baseadas em FIDO2/WebAuthn (passkeys), que resistem a phishing porque a credencial é vinculada criptograficamente ao domínio real do site — um site falso não consegue acioná-la.

O elo mais frágil costuma ser a senha. Armazená-la corretamente — com hashing lento e salt — é inegociável; é o que separa um vazamento controlável de uma catástrofe. Aprofunde em Segurança de senhas: hashing, salt e bcrypt e, para os fundamentos dos algoritmos, em O que é criptografia? Simétrica, assimétrica e hashing.

Autenticação não é o mesmo que identificação

Vale uma distinção fina: identificação é apenas afirmar quem você é (digitar o e-mail); autenticação é provar essa afirmação (apresentar a senha correta). O campo de login identifica; a senha autentica. Sistemas que confundem os dois — por exemplo, concedendo acesso só porque alguém forneceu um e-mail válido — abrem brechas óbvias.

Como funciona a autorização

Uma vez confirmada a identidade, a autorização decide o acesso. Os modelos mais comuns são:

O ponto crucial: a decisão de autorização deve acontecer no servidor, a cada requisição, com base na identidade autenticada. Confiar em informações enviadas pelo cliente (como um campo "isAdmin" no formulário) é um convite ao abuso.

Escolhendo entre RBAC e ABAC

A escolha entre os modelos é um trade-off de simplicidade contra granularidade. O RBAC é fácil de entender e auditar — você olha os papéis de um usuário e sabe o que ele pode fazer. Mas ele sofre com a "explosão de papéis": quando cada combinação de necessidades vira um papel novo (editor-regiao-sul-turno-noite), o sistema fica ingovernável.

O ABAC resolve isso decidindo por regras sobre atributos, mas ao preço de regras mais difíceis de raciocinar e auditar. Na prática, muitos sistemas reais combinam os dois: usam papéis para a estrutura macro e atributos para refinar casos como "só o dono do documento pode editá-lo". Esse caso de propriedade do recurso é onde muitos sistemas escorregam, como veremos a seguir.

# RBAC puro responde "este papel pode editar documentos?"
def pode_editar(usuario, documento):
    if "editor" not in usuario.papeis:
        return False
    # ABAC refina: além do papel, checa a propriedade do recurso
    return documento.dono_id == usuario.id or "admin" in usuario.papeis

Esse trecho ilustra a regra de ouro: ter o papel certo não basta; a decisão precisa amarrar a identidade ao recurso específico que está sendo acessado.

O erro mais comum: confundir os dois

Muitas falhas nascem de assumir que autenticar é suficiente. Um sistema que verifica corretamente quem é o usuário, mas não checa se aquele usuário específico pode acessar aquele recurso, está vulnerável. O caso clássico é o IDOR (Insecure Direct Object Reference):

GET /api/pedidos/1001   → meu pedido (ok)
GET /api/pedidos/1002   → pedido de outro usuário (deveria ser bloqueado!)

Se a aplicação só verifica que você está logado, mas não que o pedido 1002 pertence a você, qualquer usuário autenticado lê dados alheios. A identidade estava correta; a autorização falhou. Por isso a regra é: estar logado nunca implica ter acesso a tudo.

O IDOR é insidioso porque o código parece correto numa leitura rápida: há um middleware de autenticação, o usuário está logado, a query funciona. O que falta é uma checagem de propriedade que quase sempre fica implícita na cabeça do desenvolvedor e nunca chega ao código. A correção é tornar essa verificação explícita e impossível de esquecer:

@app.get("/api/pedidos/{pedido_id}")
def ver_pedido(pedido_id, usuario=Depends(autenticar)):
    pedido = db.buscar_pedido(pedido_id)
    if pedido is None:
        raise NotFound()
    # A checagem que evita o IDOR — sem ela, autenticar não basta
    if pedido.dono_id != usuario.id and "admin" not in usuario.papeis:
        raise Forbidden()
    return pedido

Uma estratégia ainda mais robusta é filtrar pela identidade já na consulta ao banco (WHERE dono_id = :usuario), de modo que recursos de outros donos sequer apareçam. Assim, esquecer a checagem resulta em "não encontrado", e não em vazamento.

401 vs 403: o status certo importa

A diferença entre os dois conceitos aparece até nos códigos HTTP. O 401 Unauthorized significa, apesar do nome, falha de autenticação — você não provou quem é (faça login). Já o 403 Forbidden significa falha de autorização — você está autenticado, mas não tem permissão para aquele recurso. Trocar um pelo outro confunde clientes da API e dificulta o diagnóstico. Use 401 quando faltam ou são inválidas as credenciais, e 403 quando a identidade é conhecida mas o acesso é negado.

Princípios de projeto que evitam falhas

Dois princípios de Saltzer e Schroeder (1975), clássicos da segurança de sistemas, orientam um bom controle de acesso:

Esses princípios continuam atuais e aparecem nos requisitos verificáveis do OWASP ASVS, que define controles concretos para autenticação, gestão de sessão e controle de acesso (OWASP Foundation, 2021). Adotá-los como padrão de projeto, e não como exceção, é o que torna um sistema resiliente.

Vale acrescentar o princípio da centralização da decisão de acesso. Espalhar checagens de permissão por dezenas de controladores garante que, mais cedo ou mais tarde, alguém esquecerá uma. Concentrar a lógica de autorização em um ponto único — um middleware, um serviço de políticas, um gateway — torna a regra auditável e reduz a chance de inconsistência. É a diferença entre confiar na disciplina de cada desenvolvedor e confiar na arquitetura.

Por fim, a negação por padrão deve valer também para rotas novas. Um sistema seguro recusa o acesso a qualquer endpoint que não tenha sido explicitamente liberado, em vez de liberar tudo e tentar bloquear caso a caso. Esquecer de proteger uma rota nova deve resultar em "negado", não em "exposto".

Um fluxo completo, do login ao recurso

Para amarrar os conceitos, vale percorrer um fluxo de acesso real, passo a passo, identificando onde cada etapa é autenticação e onde é autorização:

Repare que os passos 2 e 3 respondem "quem é você?" e os passos 4 e 5 lidam com "o que você pode fazer?". O passo 5 se repete em toda requisição subsequente; a autenticação acontece uma vez por sessão, mas a autorização é contínua. Confundir essa cadência — autenticar a cada requisição é caro; autorizar só no login é inseguro — é uma fonte clássica de problemas.

Identificação → AuthN (fator 1) → AuthN (fator 2) → sessão → AuthZ (a cada request)
   "sou eu"        "eu sei"          "eu tenho"      "lembra"   "posso isto?"

Onde cada decisão deve morar

Uma heurística útil para projetar: a autenticação pertence à borda, em um ponto de entrada bem definido (um serviço de identidade, um gateway), e seu resultado — a identidade verificada — flui para o resto do sistema. Já a autorização pertence o mais perto possível do recurso, porque só ali se conhece a propriedade e o contexto necessários para decidir. Tentar autorizar longe do recurso (por exemplo, embutindo todas as permissões no token na borda) leva justamente ao problema de permissões obsoletas que veremos a seguir. Manter identidade e autoridade em camadas distintas mantém o sistema flexível: você pode trocar o método de login sem mexer nas regras de acesso, e ajustar permissões sem afetar o login.

Onde a sessão entra

Depois de autenticar, a aplicação precisa lembrar que você já se identificou nas próximas requisições, sem pedir senha a cada clique. É aí que entram sessões e tokens:

Quando o acesso envolve delegação — permitir que um app aja em seu nome em outro serviço sem entregar sua senha — entra o protocolo de O que é OAuth 2.0? Delegação de acesso explicada. Vale destacar que o OAuth 2.0 é, em sua essência, um framework de autorização, não de autenticação — outra distinção que reforça por que separar os conceitos importa.

O perigo de colocar autorização no token

Há uma armadilha sutil aqui. Tokens autocontidos como o JWT são tentadores para carregar permissões ("este usuário é admin"), porque evita uma consulta ao banco. O problema é que o token é emitido uma vez e vale até expirar. Se você revoga o papel de admin de alguém, mas a permissão está cravada num JWT válido por uma hora, essa pessoa continua admin durante uma hora. Para autorização que muda com frequência — concessão e revogação de acesso —, o token deve carregar apenas identidade, e a autoridade deve ser resolvida ao vivo no servidor a cada requisição (ou com um cache curto). Essa é justamente a razão de a autorização ser dinâmica, e não estática como a identidade.

Sessões e tokens têm trade-offs de revogação

A escolha entre sessão com cookie e token autocontido também é uma escolha sobre revogação. Uma sessão guardada no servidor pode ser invalidada na hora: basta apagá-la do armazenamento e o próximo acesso é recusado. Já um JWT autocontido é válido por sua própria assinatura até expirar, o que torna o "logout do lado do servidor" mais difícil — geralmente exige uma lista de tokens revogados ou prazos de expiração curtos com renovação por um refresh token. Não há resposta única: sessões dão controle e simplicidade de revogação ao custo de estado no servidor; tokens dão escalabilidade sem estado ao custo de revogação mais complexa. O que não muda é o princípio: dados de autorização sensíveis a mudança não devem ficar congelados em um token de vida longa.

Perguntas frequentes

Autenticação ou autorização vem primeiro? Sempre autenticação. Você precisa estabelecer quem é a identidade antes de decidir o que ela pode fazer. A única exceção aparente são recursos públicos, que não exigem nenhuma das duas.

MFA é autenticação ou autorização? É autenticação. O MFA fortalece a verificação de identidade somando fatores; ele não decide o que você pode acessar depois de logado.

OAuth 2.0 serve para login? Estritamente, OAuth 2.0 é um protocolo de autorização (delegação de acesso). Para login (autenticação) usa-se o OpenID Connect, que é uma camada de identidade construída sobre o OAuth 2.0. Confundir os dois é um erro comum de projeto.

Posso confiar no campo "role" enviado pelo cliente? Nunca. Qualquer dado vindo do cliente — formulário, header, corpo da requisição — pode ser forjado. A decisão de autorização deve usar a identidade autenticada no servidor e dados que só o servidor controla.

RBAC ou ABAC para o meu sistema? Comece com RBAC pela simplicidade e adicione regras baseadas em atributos (como propriedade do recurso) onde o RBAC puro não dá conta. A maioria dos sistemas reais é um híbrido.

Conclusão

Autenticação e autorização são etapas distintas e complementares: primeiro você prova quem é, depois o sistema decide o que você pode fazer. Confundi-las leva a falhas como o IDOR, em que usuários legítimos acessam recursos que não são deles. Para construir um controle de acesso sólido, autentique com fatores fortes e MFA, autorize sempre no servidor a cada requisição, centralize a decisão de acesso e adote como padrão os princípios de privilégio mínimo e negação por padrão (Saltzer e Schroeder, 1975). Essa clareza conceitual é a base de praticamente toda a segurança de acesso.

Referências