Auth vs Authz: a diferença que todo mundo confunde

O problema

Tem muito sistema que pensa assim:

“Se a pessoa fez login, entao esta tudo certo.”

Não esta.

Login não responde tudo.

Ele responde uma coisa só:

• quem essa pessoa provavelmente e

Mas o sistema ainda precisa responder outra:

• essa pessoa pode fazer esta ação, neste recurso, agora?

Modelo mental

Pense assim:

• auth ou autenticação: provar identidade
• authz ou autorização: decidir acesso

As perguntas sao diferentes:

• quem e você?
• o que você pode fazer?

Quando essas perguntas viram a mesma coisa na cabeca do time, aparecem erros classicos:

• usuário logado acessando recurso que não deveria
• regra de acesso escondida só na UI
• papel genérico demais como se resolvesse todos os casos

Quebrando o problema

Primeiro o sistema prova identidade

Senha, link magico, SSO, token ou sessao servem para isso:

• ligar uma request a uma identidade

Sem identidade confiavel, nem da para começar a falar de permissao.

Depois o backend decide acesso

A pergunta deixa de ser “quem e você?” e passa a ser:

• você pode editar este pedido?
• você pode ver este relatório?
• você pode excluir este usuário?

Perceba o detalhe:

autorização quase sempre depende de:

• ação
• recurso
• contexto

Não só de um papel genérico qualquer.

A UI ajuda, mas não manda

Esconder botao, travar menu e ajustar tela sao coisas boas de UX.

Mas a decisão real continua no backend.

Se a regra vive só no frontend, ela não existe de verdade.

Permissao sem contexto costuma ser rasa demais

isAdmin === true resolve alguns casos.

Mas muitos cenarios reais pedem algo mais fino:

• dono do recurso
• time certo
• escopo do tenant
• estado do objeto

Autorização madura costuma depender do recurso concreto, não só do tipo de usuário.

Exemplo simples

Imagine um dashboard que esconde o botao “Excluir usuário” de quem não e admin.

Na interface, parece tudo certo.

Mas se o backend aceita:

DELETE /users/123

sem validar a permissao real, qualquer pessoa autenticada pode tentar a chamada com cURL, script ou devtools.

O problema não e um botao aparecendo.

O problema e tratar regra visual como se fosse controle de acesso real.

Erros comuns

• Assumir que usuário logado já e usuário autorizado.
• Confiar na interface para bloquear operação sensivel.
• Usar role ampla demais sem olhar recurso e contexto.
• Esquecer que cada ação crítica precisa de checagem no backend.
• Falar de auth e authz como se fossem etapas intercambiaveis.

Como um senior pensa

Quem tem mais experiência separa cedo:

• identidade
• sessao
• permissao

O raciocínio costuma ser:

“Primeiro eu sei quem fez a request. Depois eu avalio se essa identidade pode agir sobre este recurso específico. Se a resposta depende só da UI, a arquitetura ainda esta fraca.”

Essa separação melhora:

• segurança
• explicação em entrevista
• desenho de API
• manutenção de regra

O que o entrevistador quer ver

Em entrevista, esse tema mede clareza conceitual muito rápido.

O avaliador quer ver se você:

• separa identidade de acesso
• entende autorização como decisão contextual
• não terceiriza segurança para o frontend
• consegue explicar isso sem jargao vazio

Uma resposta forte costuma soar assim:

“Autenticação me diz quem esta fazendo a request. Autorização decide se essa identidade pode executar aquela ação naquele recurso. Eu posso esconder ação na UI por UX, mas a decisão real continua no backend.”

Login prova identidade. Permissao prova limite.

Usuário autenticado sem autorização continua sem poder fazer a ação.