RBAC na prática: Implementação de autorização segura para a sua aplicação
Guia completo para o Controle de Acesso Baseado em Funções (RBAC): Domine o design de permissões, gestão de funções e autorização segura com uma implementação prática de CMS.
YijunDeveloper
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
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.
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.
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
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.
Agora que temos nossa API e permissões definidas, podemos criar funções que agrupam estas permissões logicamente:
Permissão/Função
👑 Admin
📝 Editor
✍️ Autor
Descrição
Acesso total ao sistema para gestão completa de conteúdo
Pode visualizar todos os artigos e controlar o estado de publicação
Pode criar novos artigos no sistema
list:articles
✅
✅
❌
read:articles
✅
✅
❌
create:articles
✅
❌
✅
update:articles
✅
❌
❌
delete:articles
✅
❌
❌
publish:articles
✅
✅
❌
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
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.
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.
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.
