RBAC na prática: Implementação de autorização segura para a sua aplicação

Está a ter dificuldades em implementar um sistema de autorização seguro e escalável para a sua aplicação? O Controle de Acesso Baseado em Funções (RBAC) é o padrão da indústria para gerir permissões de utilizadores, mas implementá-lo corretamente pode ser desafiador. Este tutorial irá mostrar-lhe como construir um sistema robusto de RBAC usando um exemplo real de Sistema de Gestão de Conteúdos (CMS).

Ao seguir este guia, você aprenderá:

• ✨ Como desenhar e implementar permissões granulares que oferecem controlo preciso
• 🔒 Melhores práticas para organizar permissões em funções significativas
• 👤 Técnicas para lidar eficazmente com a posse de recursos
• 🚀 Formas de tornar o seu sistema de autorização escalável e sustentável
• 💡 Implementação prática usando um exemplo real de CMS

O código fonte completo deste tutorial está disponível no GitHub.

Compreendendo os fundamentos do RBAC#

O Controle de Acesso Baseado em Funções é mais do que apenas atribuir permissões aos utilizadores. Trata-se de criar uma abordagem estruturada para autorização que equilibre segurança com sustentabilidade.

Pode aprender mais sobre O que é o RBAC no Auth Wiki.

Aqui estão os princípios chave que vamos seguir na nossa implementação:

Design de permissões granulares#

Permissões granulares dão-lhe controlo preciso sobre o que os utilizadores podem fazer no seu sistema. Em vez de níveis de acesso amplos, como "admin" ou "utilizador", definimos ações específicas que os utilizadores podem realizar em recursos. Por exemplo:

• read:articles - Ver qualquer artigo no sistema
• create:articles - Criar novos artigos
• update:articles - Modificar artigos existentes
• publish:articles - Alterar o estado de publicação dos artigos

Posse de recursos e controlo de acesso#

A posse de recursos é um conceito fundamental no design de autorização do nosso CMS. Enquanto o RBAC define quais ações diferentes funções podem executar, a posse adiciona uma dimensão pessoal ao controlo de acesso:

• Autores têm automaticamente acesso aos artigos que criaram
• Este modelo de posse natural significa que os autores podem sempre ver e editar o seu próprio conteúdo
• O sistema verifica ambas as permissões de função OU posse ao lidar com operações de artigos
• Por exemplo, mesmo sem a permissão update:articles, um autor ainda pode editar os seus próprios artigos
• Este design reduz a necessidade de permissões de função extra enquanto mantém a segurança

Esta abordagem de duas camadas (funções + posse) cria um sistema mais intuitivo e seguro. Editores e administradores ainda podem gerir todo o conteúdo através das suas permissões de funções, enquanto os autores mantêm o controlo sobre o seu próprio trabalho.

Desenhando APIs seguras#

Comecemos por desenhar a funcionalidade principal do nosso CMS através dos seus pontos de extremidade API:

Implementar controlo de acesso para a sua API#

Para cada ponto de extremidade, precisamos considerar dois aspetos do controlo de acesso:

1. Posse de recursos - O utilizador é dono deste recurso?
2. Permissões baseadas em função - A função do utilizador permite esta operação?

Aqui está como vamos lidar com o acesso para cada ponto de extremidade:

Criando um sistema de permissões que escala#

Com base nos nossos requisitos de acesso à API, podemos definir estas permissões:

Note que estas permissões só são necessárias ao aceder recursos que não possui. Donos de artigos podem automaticamente:

• Ver seus próprios artigos (não é necessário read:articles)
• Editar seus próprios artigos (não é necessário update:articles)
• Apagar seus próprios artigos (não é necessário delete:articles)

Criando funções eficazes#

Agora que temos nossa API e permissões definidas, podemos criar funções que agrupam estas permissões logicamente:

Nota: Autores têm automaticamente permissões de leitura/atualização/eliminação para os seus próprios artigos, independentemente das permissões de função.

Cada função é desenhada com responsabilidades específicas em mente:

• Admin: Tem controlo total sobre o CMS, incluindo todas as operações de artigos
• Editor: Foca-se na revisão e gestão de publicação de conteúdo
• Autor: Especializa-se na criação de conteúdo

Esta estrutura de funções cria uma clara separação de preocupações:

• Autores focam-se na criação de conteúdo
• Editores gerem a qualidade e visibilidade do conteúdo
• Admins mantêm o controlo global do sistema

Configurar RBAC no Logto#

Antes de começar, precisa criar uma conta no Logto Cloud, ou pode também usar uma instância do Logto auto-hospedada usando a versão OSS do Logto.

Mas para este tutorial, utilizaremos o Logto Cloud para simplicidade.

Configurando a sua aplicação#

1. Vá para "Aplicações" no Console do Logto para criar uma nova aplicação react
   • Nome da aplicação: Sistema de Gestão de Conteúdos
   • Tipo de aplicação: Aplicação Web Tradicional
   • URIs de redirecionamento: http://localhost:5173/callback

Configurando recursos e permissões da API#

1. Vá para "Recursos da API" no Console do Logto para criar um novo recurso de API
   • Nome da API: API CMS
   • Identificador da API: https://api.cms.com
   • Adicionar permissões ao recurso da API
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

Criando funções#

Vá para Funções no Console do Logto para criar as seguintes funções para o CMS

• Admin
  • com todas as permissões
• Editor
  • com read:articles, list:articles, publish:articles
• Autor
  • com create:articles

Atribuindo funções aos utilizadores#

Vá para a seção "Gestão de utilizadores" no Console do Logto para criar utilizadores.

Na aba "Funções" dos detalhes do utilizador, pode atribuir funções ao utilizador.

No nosso exemplo, criamos 3 utilizadores com as seguintes funções:

• Alex: Admin
• Bob: Editor
• Charlie: Autor

Integrar o seu frontend com o Logto RBAC#

Agora que configurámos o RBAC no Logto, podemos começar a integrá-lo no nosso frontend.

Primeiro, siga os Inícios Rápidos do Logto para integrar o Logto na sua aplicação.

No nosso exemplo, usamos React para demonstração.

Depois de configurar o Logto na sua aplicação, precisamos adicionar as configurações do RBAC para o Logto funcionar.

Lembre-se de sair e entrar novamente para fazer esta alteração ter efeito se já estiver conectado.

Quando o utilizador se inscrever com o Logto e solicitar um token de acesso para os recursos da API especificados acima, o Logto adicionará escopos (permissões) relacionados à função do utilizador ao token de acesso.

Pode usar getAccessTokenClaims do hook useLogto para obter os escopos do token de acesso.

E pode usar o userScopes para verificar se o utilizador tem permissão para aceder ao recurso.

Integrar o seu backend com o Logto RBAC#

Agora, é hora de integrar o Logto RBAC no seu backend.

Middleware de autorização do backend#

Primeiro, precisamos adicionar um middleware no backend para verificar as permissões do utilizador, verificar se o utilizador está logado e determinar se eles têm as permissões necessárias para aceder a certas APIs.

Como pode ver, neste middleware, verificamos se o pedido do frontend contém um token de acesso válido e verificamos se o público do token de acesso corresponde ao recurso da API que criámos no Console do Logto.

O motivo para verificar o recurso da API é que o nosso recurso da API representa, na verdade, os recursos do nosso backend CMS, e todas as nossas permissões do CMS estão associadas a este recurso da API.

Como este recurso da API representa os recursos do CMS no Logto, no nosso código frontend, incluímos o token de acesso correspondente ao fazer pedidos de API ao backend:

Agora podemos usar o middleware requireAuth para proteger nossos pontos de extremidade da API.

Protegendo pontos de extremidade da API#

Para APIs que devem ser acessíveis apenas a utilizadores com permissões específicas, podemos adicionar restrições diretamente no middleware. Por exemplo, a API de criação de artigos deve ser acessível apenas a utilizadores com a permissão create:articles:

Para APIs que precisam verificar tanto permissões quanto posse de recursos, podemos usar a função hasScopes. Por exemplo, na API de listagem de artigos, utilizadores com a permissão list:articles podem acessar todos os artigos, enquanto autores podem acessar seus próprios artigos criados:

Neste ponto, completámos a implementação do RBAC. Pode verificar o código fonte completo para ver a implementação completa.

Testar a implementação do CMS RBAC#

Agora, testemos a implementação do CMS RBAC usando os três utilizadores que acabámos de criar.

Primeiro, vamos entrar com Alex e Charles, respetivamente, e criar alguns artigos.

Uma vez que Alex tem a função Admin, ele pode criar, apagar, atualizar, publicar e ver todos os artigos.

Charles, tendo a função de Autor, pode apenas criar seus próprios artigos e só pode ver, atualizar e apagar artigos que possui.

Bob, com a função de Editor, pode ver e publicar todos os artigos, mas não pode criar, atualizar ou apagar.

Conclusão#

Parabéns! Você aprendeu como implementar um sistema robusto de RBAC na sua aplicação.

Para cenários mais complexos, como construir aplicações multi-tenant, o Logto fornece suporte organizacional compreensivo. Consulte o nosso guia Construindo uma aplicação SaaS multi-tenant: Um guia completo desde o design à implementação para aprender mais sobre a implementação de controlo de acesso a nível organizacional.

Feliz codificação! 🚀