DS & II

Capítulo 15 - Autorização e Papéis

Leitura de 4 min

🚀 Capítulo 15: Autorização e Papéis (Tema: Naruto)

NOTE

Este capítulo utiliza a temática de Naruto para explicar a Autorização. Na Vila da Folha, um Genin não pode ler os pergaminhos proibidos que só os Hokages têm acesso!

1. 🎯 Objetivo da Aula

Compreender a diferença entre Autenticação (quem você é) e Autorização (o que você pode fazer), e como implementar o controle de acesso baseado em papéis (RBAC).

2. 🏢 O Cenário Prático (Seu Desafio)

Você foi contratado pelo Hokage para organizar o sistema de arquivos da Vila da Folha. Nem todo ninja pode ver tudo.

  • Genin: Só pode ver missões de Rank D e C.
  • Chunin: Pode ver missões de Rank B e A.
  • Jonin: Pode ver todas as missões e ler pergaminhos de jutsus avançados.
  • Hokage: Tem acesso total e pode apagar registros.

Seu desafio é criar as regras de bloqueio para que um Genin não consiga acessar a sala do Hokage!

3. 🧠 Fundamentos: A Teoria Traduzida

Muitas pessoas confundem esses dois conceitos, mas eles são bem diferentes:

🔑 1. Autenticação (Authentication)

É o ato de verificar quem você é. Geralmente envolve usuário, senha ou um token JWT.

  • Na Vila: É o ninja mostrar a sua bandana e identificação no portão da vila.

📜 2. Autorização (Authorization)

É o ato de verificar o que você tem permissão para fazer. Acontece sempre DEPOIS da autenticação.

  • Na Vila: O guarda vê que você é um Genin e te barra na porta da biblioteca de jutsus proibidos.

👥 3. RBAC (Role-Based Access Control)

É o Controle de Acesso Baseado em Papéis (Funções). Em vez de dar permissão para cada usuário individualmente, criamos “Papéis” (Roles) como ADMIN, USER, EDITOR e damos as permissões para o papel. Os usuários herdam as permissões do papel que possuem.

4. 📖 Exemplo Guiado: Middleware de Permissão

Podemos usar um middleware (como vimos no capítulo 12) para verificar o papel do usuário que está no token JWT:

const verificarAcessoHokage = (req, res, next) => {
    // Supondo que o papel veio no token decodificado
    const papelUsuario = req.usuario.papel; 
 
    if (papelUsuario !== 'HOKAGE') {
        return res.status(403).json({ 
            erro: "Acesso negado. Apenas o Hokage pode acessar esta área." 
        });
    }
    
    next(); // Se for Hokage, permite o acesso!
};

5. 🛠️ Prática Obrigatória 1: Quem pode fazer o quê?

Com base no cenário da Vila da Folha, diga qual status HTTP (200, 401 ou 403) o servidor deve retornar nas seguintes situações:

  1. Um Genin tenta acessar a rota /permissao/jutsus-proibidos.
  2. Um usuário tenta acessar a rota /missoes sem enviar nenhum token de login.
  3. O Hokage acessa a rota /painel-de-controle.

6. 🛠️ Prática Obrigatória 2: Autenticação vs Autorização

Diga se as situações abaixo são problemas de Autenticação ou de Autorização:

  1. O usuário esqueceu a senha e não consegue entrar no sistema.
  2. O usuário conseguiu entrar no sistema, mas tentou deletar um produto e apareceu “Ação não permitida para o seu nível”.

7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 15 Backend) e clique em Commit to main.
  2. Envie para a Nuvem (Push): Clique em Push origin.

8. 📂 Estrutura de Pastas

mod_07_backend_e_apis/
├── capitulos/
│   ├── capitulo_15_autorizacao.md
│   └── codigos/
│       └── cap15/
│           └── controle_acesso.js

9. 💡 Checkpoint de Lógica

Por que é importante fazer a validação de autorização no Backend, mesmo que o botão de “Deletar” já esteja escondido no Frontend para usuários comuns?

10. 🔥 Desafio de Fixação

Pesquise o que significa a sigla ABAC (Attribute-Based Access Control) e como ela difere do RBAC.

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. Genin em área proibida → 403 Forbidden (Ele está autenticado, mas não tem autorização).
  2. Sem token → 401 Unauthorized (Não sabemos quem ele é).
  3. Hokage no painel → 200 OK (Ele tem acesso total).

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks