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:

• Autenticação (AuthN): o processo de verificar a identidade de quem está acessando. Responde "você é quem diz ser?".
• Autorização (AuthZ): o processo de decidir o que uma identidade já verificada pode acessar ou fazer. Responde "você tem permissão para isto?".

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:

• Algo que você sabe: senha, PIN.
• Algo que você tem: celular com app autenticador, token físico.
• Algo que você é: biometria (impressão digital, rosto).

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:

• RBAC (Role-Based Access Control): permissões atreladas a papéis (admin, editor, leitor). O usuário recebe papéis, e os papéis carregam permissões. Simples e muito usado.
• ABAC (Attribute-Based Access Control): decisões baseadas em atributos do usuário, do recurso e do contexto (departamento, horário, dono do recurso). Mais flexível e granular.
• ACL (Access Control List): lista explícita de quem pode o quê em cada recurso.

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:

• Privilégio mínimo (least privilege): cada usuário e cada componente deve ter apenas as permissões estritamente necessárias. Menos privilégio significa menos estrago em caso de comprometimento.
• Padrão à prova de falha (fail-safe defaults): a decisão padrão deve ser negar. O acesso só é concedido por uma regra explícita de permissão, nunca por ausência de proibição.

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:

1. Identificação: o usuário informa o e-mail. Isso ainda não prova nada.
2. Autenticação (1º fator): o usuário fornece a senha; o servidor compara o hash armazenado. Confirma "você sabe o segredo".
3. Autenticação (2º fator): o servidor pede um código TOTP ou um toque na passkey. Confirma "você possui o dispositivo". Aqui termina a verificação de identidade.
4. Emissão de sessão: estabelecida a identidade, o servidor cria uma sessão ou emite um token para que o usuário não precise repetir o login a cada clique.
5. Autorização (por requisição): a cada acesso a um recurso, o servidor checa, com base na identidade da sessão, se aquela ação é permitida — incluindo a propriedade do recurso.

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:

• Sessões com cookie: o servidor guarda o estado e envia um identificador de sessão.
• Tokens autocontidos: o próprio token carrega as informações de identidade, validadas por assinatura — modelo detalhado em O que é JWT (JSON Web Token)?.

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#

• Jerome H. Saltzer, Michael D. Schroeder (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE.
• OWASP Foundation (2021). OWASP Application Security Verification Standard 4.0. OWASP.
• D. Hardt (2012). The OAuth 2.0 Authorization Framework. RFC 6749, IETF.
• W3C (2021). Web Authentication: An API for accessing Public Key Credentials (WebAuthn) Level 2. W3C Recommendation.