Autorização baseada em roles

Resumo

Após autenticar, a autorização decide o que o usuário pode fazer. Cobrimos [Authorize(Roles = ...)] e políticas (policies) baseadas em claims para regras mais ricas.

1. Objetivos de Aprendizagem#

• Restringir endpoints por role.
• Definir políticas de autorização baseadas em claims.
• Diferenciar autenticação de autorização.

2. Pré-requisitos#

• Autenticação JWT com roles nas claims (tópico 40.2).

3. Conceito#

• Autenticação: quem é o usuário (Módulo 40.2).
• Autorização: o que ele pode fazer.

Roles são grupos (Administrator, Manager). Para regras além de "pertence à role X", usamos policies que avaliam claims (ex.: Departamento = Vendas). O porquê das policies: separam a regra de autorização do código do controller e são reutilizáveis.

4. Mão na Massa#

4.1. Setup#

Roles já viajam nas claims do JWT (ClaimTypes.Role).

4.2. Implementação Passo a Passo#

1. Autorização por role:

[Authorize(Roles = "Administrator")]
[HttpDelete("{id:guid}")]
public async Task<IActionResult> Deletar(Guid id) { /* ... */ return NoContent(); }

2. Múltiplas roles e combinação:

[Authorize(Roles = "Administrator,Manager")]
[HttpPost]
public async Task<IActionResult> Criar(/* ... */) => Ok();

3. Policy baseada em claim:

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("SomenteVendas", policy =>
        policy.RequireClaim("Departamento", "Vendas"));

[Authorize(Policy = "SomenteVendas")]
[HttpGet("relatorios")]
public IActionResult Relatorios() => Ok();

4.3. Executando#

# token sem a role Administrator recebe 403 no DELETE
curl -i -X DELETE http://localhost:5000/api/produtos/{id} -H "Authorization: Bearer <tokenSemRole>"
# HTTP/1.1 403 Forbidden

5. Exemplo Completo#

Diferença de status:

• Sem token / token inválido → 401 Unauthorized.
• Token válido, mas sem permissão → 403 Forbidden.

6. Boas Práticas e Armadilhas#

Atenção

confie nas roles/claims do token validado, não em valores enviados pelo cliente em outro lugar (query/body) — estes podem ser forjados.

7. Segurança e Produção#

• Princípio do menor privilégio: conceda apenas o necessário.
• Autorize também na camada de serviço para operações críticas, não só via atributo (defesa em profundidade).
• Verifique ownership (o recurso pertence ao usuário) para evitar IDOR mesmo com a role correta.

8. Exercícios#

• Fácil: restrinja o DELETE a Administrator.
• Médio: crie uma policy que exija a claim MaiorDeIdade = true.
• Desafio: implemente um AuthorizationHandler customizado (requisito baseado em recurso).

9. Resumo#

Autorização por role ([Authorize(Roles=...)]) e policies baseadas em claims controlam o acesso após a autenticação. Respeite 401 vs 403, menor privilégio e verifique ownership.

10. Próximos Passos#

Módulo 41: refresh token para renovar o acesso sem novo login.

11. Referências#

• Microsoft Learn — Autorização baseada em roles
• Microsoft Learn — Autorização baseada em policies
• Microsoft Learn — Autorização baseada em recursos