Authn vs Authz: a diferença e as armadilhas

⏱ 11 min·⭐ 50 XP

Pré-requisitos (0/1)0%

⬜🎯 Threat modeling com STRIDE: de onde vêm os ataques(Security Engineering)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

A ordem importa

Pipeline correto de request protegido:

// 1. Authn (quem é?) — middleware JWT, session, etc.
const user = await authenticate(req);
if (!user) return 401;

// 2. Authz (pode?) — check policy pro recurso
const canEdit = await authorize(user, 'edit', resource);
if (!canEdit) return 403;

// 3. Handler — assume identity e permission válidas
await handleEdit(req, user, resource);

401 vs 403: 401 Unauthorized (mal nomeado — na verdade "unauthenticated"). 403 Forbidden (autenticado mas sem permissão). Não misture.

Modelos de authz comparados

Modelo	Quando usar	Exemplo
RBAC (role-based)	90% dos apps — simples	admin, editor, viewer com perms fixas
ABAC (attribute-based)	Multi-tenant, contexto	AWS IAM com Condition, OPA/Rego
ReBAC (relationship)	Sharing-heavy (Drive, Notion)	Zanzibar, SpiceDB, OpenFGA
PBAC (policy-based)	Compliance complexa	OPA Gatekeeper em Kubernetes

ModeloRBAC (role-based)

Quando usar90% dos apps — simples

Exemploadmin, editor, viewer com perms fixas

ModeloABAC (attribute-based)

Quando usarMulti-tenant, contexto

ExemploAWS IAM com Condition, OPA/Rego

ModeloReBAC (relationship)

Quando usarSharing-heavy (Drive, Notion)

ExemploZanzibar, SpiceDB, OpenFGA

ModeloPBAC (policy-based)

Quando usarCompliance complexa

ExemploOPA Gatekeeper em Kubernetes

Tipar authn no TS — nunca esquecer

// Request padrão: user pode ser undefined — falha silenciosa
type UnauthenticatedRequest = Request;

// Branded: só existe APÓS middleware authn
type AuthenticatedRequest = Request & {
  user: User;
  readonly __authenticated: true;
};

// Handler protegido só aceita o tipo branded
function editDocument(req: AuthenticatedRequest) {
  req.user // ← garantido existir, TS prova
}

// Middleware transforma
function requireAuth(req: Request): AuthenticatedRequest {
  const user = verifyToken(req);
  if (!user) throw new HttpError(401);
  return Object.assign(req, { user, __authenticated: true as const });
}

💡

Este padrão elimina a classe inteira de bugs "esqueci de checar autenticação". O TS não compila sem o middleware primeiro.

Quiz rápido

Por que a ordem entre autenticar e autorizar importa?

Armadilhas clássicas

IDOR (Insecure Direct Object Reference): sem checar se 123 é o user logado. Sempre comparar: .
Authz em client: esconder botão no front não protege. Toda regra vai no server.
Race na autorização: checar perm e executar em steps separados. Entre os dois, estado pode mudar. Use transação ou check dentro do UPDATE.
Escalation lateral: user nível N pode editar dados de outro user nível N. Se o recurso tem dono, a perm PRECISA incluir owner check.

Perguntas frequentes

❓ Qual a diferença entre autenticação e autorização?

Autenticação prova quem você é; autorização decide o que você pode fazer. A confusão custa: sistema que autentica bem e autoriza mal deixa qualquer usuário logado acessar dado de qualquer outro — que é a vulnerabilidade mais comum de aplicação web.

❓ Onde a autorização deve ser verificada?

No servidor, em cada operação, sobre o RECURSO específico — não só na entrada e não na interface. Esconder o botão não protege nada. A verificação por recurso é o que falta quando o identificador na URL pode ser trocado pelo de outro usuário.

❓ Papéis ou atributos para autorizar?

Papéis quando as permissões se agrupam bem e são poucas — mais simples de entender e auditar. Atributos quando a decisão depende do contexto: dono do recurso, departamento, horário. A maioria dos sistemas precisa dos dois, e começar por papéis é razoável.

Fixando

Quiz rápido

Qual é a armadilha clássica em controle de acesso a recursos?

Quiz rápido

Qual modelo de autorização escala melhor quando as regras dependem de atributos do recurso e do contexto?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🔐

OAuth2 e OIDC do zero: fluxos e PKCE

Security Engineering · 15 min · +65 XP

→

Temas deste módulo

Segurança de IA

Discussão

Carregando comentários…

Authn vs Authz: a diferença e as armadilhas

⏱ 11 min·⭐ 50 XP

Pré-requisitos (0/1)0%

⬜🎯 Threat modeling com STRIDE: de onde vêm os ataques(Security Engineering)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

A ordem importa

Pipeline correto de request protegido:

// 1. Authn (quem é?) — middleware JWT, session, etc.
const user = await authenticate(req);
if (!user) return 401;

// 2. Authz (pode?) — check policy pro recurso
const canEdit = await authorize(user, 'edit', resource);
if (!canEdit) return 403;

// 3. Handler — assume identity e permission válidas
await handleEdit(req, user, resource);

401 vs 403: 401 Unauthorized (mal nomeado — na verdade "unauthenticated"). 403 Forbidden (autenticado mas sem permissão). Não misture.

Modelos de authz comparados

Modelo	Quando usar	Exemplo
RBAC (role-based)	90% dos apps — simples	admin, editor, viewer com perms fixas
ABAC (attribute-based)	Multi-tenant, contexto	AWS IAM com Condition, OPA/Rego
ReBAC (relationship)	Sharing-heavy (Drive, Notion)	Zanzibar, SpiceDB, OpenFGA
PBAC (policy-based)	Compliance complexa	OPA Gatekeeper em Kubernetes

ModeloRBAC (role-based)

Quando usar90% dos apps — simples

Exemploadmin, editor, viewer com perms fixas

ModeloABAC (attribute-based)

Quando usarMulti-tenant, contexto

ExemploAWS IAM com Condition, OPA/Rego

ModeloReBAC (relationship)

Quando usarSharing-heavy (Drive, Notion)

ExemploZanzibar, SpiceDB, OpenFGA

ModeloPBAC (policy-based)

Quando usarCompliance complexa

ExemploOPA Gatekeeper em Kubernetes

Tipar authn no TS — nunca esquecer

// Request padrão: user pode ser undefined — falha silenciosa
type UnauthenticatedRequest = Request;

// Branded: só existe APÓS middleware authn
type AuthenticatedRequest = Request & {
  user: User;
  readonly __authenticated: true;
};

// Handler protegido só aceita o tipo branded
function editDocument(req: AuthenticatedRequest) {
  req.user // ← garantido existir, TS prova
}

// Middleware transforma
function requireAuth(req: Request): AuthenticatedRequest {
  const user = verifyToken(req);
  if (!user) throw new HttpError(401);
  return Object.assign(req, { user, __authenticated: true as const });
}

💡

Este padrão elimina a classe inteira de bugs "esqueci de checar autenticação". O TS não compila sem o middleware primeiro.

Quiz rápido

Por que a ordem entre autenticar e autorizar importa?

Armadilhas clássicas

IDOR (Insecure Direct Object Reference): sem checar se 123 é o user logado. Sempre comparar: .
Authz em client: esconder botão no front não protege. Toda regra vai no server.
Race na autorização: checar perm e executar em steps separados. Entre os dois, estado pode mudar. Use transação ou check dentro do UPDATE.
Escalation lateral: user nível N pode editar dados de outro user nível N. Se o recurso tem dono, a perm PRECISA incluir owner check.

Perguntas frequentes

❓ Qual a diferença entre autenticação e autorização?

❓ Onde a autorização deve ser verificada?

❓ Papéis ou atributos para autorizar?

Fixando

Quiz rápido

Qual é a armadilha clássica em controle de acesso a recursos?

Quiz rápido

Qual modelo de autorização escala melhor quando as regras dependem de atributos do recurso e do contexto?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🔐

OAuth2 e OIDC do zero: fluxos e PKCE

Security Engineering · 15 min · +65 XP

→

Temas deste módulo

Segurança de IA

Discussão

Carregando comentários…