實際操作 RBAC：為你的應用程式實現安全授權

你是否在為應用程式實現安全且具擴展性的授權系統而苦惱？角色基礎存取控制（RBAC）是管理用戶權限的行業標準，但正確地實施它可能具有挑戰性。本教程將向你展示如何使用真實世界的內容管理系統（CMS）範例來構建一個強健的 RBAC 系統。

透過遵循本指南，你將學會：

• ✨ 如何設計和實現細粒度的權限，讓你擁有精確的控制
• 🔒 組織權限到有意義角色的最佳實踐
• 👤 有效處理資源所有權的技術
• 🚀 使你的授權系統可擴展和可維護的方法
• 💡 使用實際 CMS 範例的實際實現

本教程的完整源代碼可在 GitHub 上獲得。

理解 RBAC 基本原理#

角色基礎存取控制不僅僅是向用戶分配權限。它是關於創建在安全性和可維護性之間取得平衡的授權結構化方法。

你可以在 Auth Wiki 中了解更多關於 什麼是 RBAC 的資訊。

以下是我們在實施中將會遵循的關鍵原則：

細粒度的權限設計#

細粒度的權限讓你精確控制用戶在系統中能執行的操作。與「管理員」或「用戶」這樣的廣泛存取層級不同，我們定義了用戶可以對資源執行的具體行動。例如：

• read:articles - 查看系統中的任何文章
• create:articles - 創建新文章
• update:articles - 修改現有文章
• publish:articles - 改變文章的發布狀態

資源所有權和存取控制#

資源所有權是我們 CMS 授權設計中的一個基本概念。雖然 RBAC 定義了不同角色可以執行的操作，但所有權為存取控制增加了一個個人維度：

• 作者自動擁有對他們創建的文章的存取權
• 這種自然的所有權模型意味著作者總是可以查看和編輯自己的內容
• 系統在處理文章操作時會同時檢查角色權限 或 所有權
• 例如，即使沒有 update:articles 權限，作者仍然可以編輯自己的文章
• 該設計在保持安全性的同時減少了額外角色權限的需要

這種雙層方法（角色 + 所有權）創造了一個更直觀和安全的系統。出版者和管理員仍然可以通過他們的角色權限管理所有內容，而作者始終保持對自己作品的控制。

設計安全的 API#

讓我們開始設計我們 CMS 的核心功能通過其 API 端點：

實施 API 的存取控制#

對於每個端點，我們需要考慮存取控制的兩個方面：

1. 資源所有權 - 用戶是否擁有此資源？
2. 角色基礎的權限 - 用戶的角色是否允許此操作？

以下是我們對每個端點的存取處理方式：

創建一個可擴展的權限系統#

基於我們的 API 存取需求，我們可以定義這些權限：

注意，這些權限僅在存取你不擁有的資源時需要。文章擁有者可以自動：

• 查看他們自己的文章（不需要 read:articles）
• 編輯他們自己的文章（不需要 update:articles）
• 刪除他們自己的文章（不需要 delete:articles）

構建有效的角色#

現在我們定義了我們的 API 和權限，我們可以創建邏輯上將這些權限組合的角色：

注意：無論角色權限如何，作者自動擁有其自己的文章的閱讀/更新/刪除權限。

每個角色的設計考慮到具體的責任：

• 管理員：擁有 CMS 的完全控制權，包括所有文章操作
• 出版者：專注於內容審查和發布管理
• 作者：專注於內容創作

這個角色結構創造了明確的責權分工：

• 作者專注於創作內容
• 出版者管理內容質量和可見性
• 管理員維護整個系統控制

在 Logto 中配置 RBAC#

在開始之前，你需要在 Logto Cloud 中創建一個帳戶，或者你也可以使用 Logto OSS 版本 來使用自行託管的 Logto 例項。

但在本教程中，我們將使用 Logto Cloud 以簡化過程。

設置應用程式#

1. 進入 Logto 控制台中的「應用程式」，創建一個新的 react 應用程式
   • 應用程式名稱：内容管理系統
   • 應用程式類型：傳統 Web 應用程式
   • 重導 URI：http://localhost:5173/callback

配置 API 資源和權限#

1. 進入 Logto 控制台中的「API 資源」，創建一個新的 API 資源
   • API 名稱：CMS API
   • API 識別符：https://api.cms.com
   • 向該 API 資源添加權限
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

創建角色#

進入 Logto 控制台中的角色，為 CMS 創建以下角色

• 管理員
  • 擁有所有許可權
• 出版者
  • 擁有 read:articles、list:articles、publish:articles
• 作者
  • 擁有 create:articles

為用戶分配角色#

進入 Logto 控制台的「用戶管理」部分來創建用戶。

在用戶詳細資料的「角色」標籤中可以分配用戶角色。

在我們的範例中，我們創建了 3 個用戶並分配以下角色：

• Alex：管理員
• Bob：出版者
• Charlie：作者

將前端與 Logto RBAC 集成#

現在，我們已經在 Logto 中設置了 RBAC，我們可以開始將其集成到前端中。

首先，按照 Logto 快速入門 說明將 Logto 集成到你的應用程式中。

在我們的範例中，我們使用 React 進行演示。

在你的應用程式中已設置 Logto 之後，我們需要為 Logto 添加 RBAC 配置。

如果你已經登入，記得登出並重新登入以使更改生效。

當用戶使用 Logto 登入並請求上述指定的 API 資源存取令牌時，Logto 將會將與用戶角色相關的範圍（權限）添加到存取令牌中。

你可以使用 useLogto 鉤子中的 getAccessTokenClaims 方法來獲取存取令牌中的範圍。

你可以用 userScopes 來檢查用戶是否有權限存取資源。

將後端與 Logto RBAC 集成#

現在，是時候將 Logto RBAC 集成到你的後端了。

後端授權中介軟體#

首先，我們需要在後端添加一個中介軟體來檢查用戶權限，驗證用戶是否已登入，以及他們是否擁有存取某些 API 的必要權限。

如你所見，在這個中介軟體中，我們驗證前端請求是否包含有效的存取令牌並檢查存取令牌的受眾是否與我們在 Logto 控制台中創建的 API 資源相符合。

驗證 API 資源的原因是我們的 API 資源實際上代表了我們 CMS 後端的資源，並且我們所有的 CMS 權限都與此 API 資源相關聯。

由於此 API 資源在 Logto 中代表了 CMS 資源，在我們的前端程式碼中，我們在向後端發送 API 請求時加入相應的存取令牌：

現在我們可以使用 requireAuth 中介軟體來保護我們的 API 端點。

保護 API 端點#

對於僅應限定具有特定權限的用戶存取的 API，我們可以直接在中介軟體中添加限制。例如，文章創建 API 只應讓具有 create:articles 權限的用戶存取：

對於需要同時檢查權限和資源所有權的 API，我們可以使用 hasScopes 函數。例如，在文章列表 API 中，具有 list:articles 權限的用戶可以存取所有文章，而作者可以存取他們自己創建的文章：

至此，我們已經完成了 RBAC 的實施。你可以查看 完整的源代碼 以查看完整的實現。

測試 CMS RBAC 實現#

現在，讓我們使用剛剛創建的三個用戶測試我們的 CMS RBAC 實現。

首先，讓我們分別使用 Alex 和 Charles 登入並創建一些文章。

由於 Alex 具有管理員角色，他們可以創建、刪除、更新、發布並查看所有文章。

Charles，具有作者角色，只能創建他們自己的文章，並且只能查看、更新和刪除他們擁有的文章。

Bob，擁有出版者角色，可以查看和發布所有文章，但不能創建、更新或刪除。

結論#

恭喜你！你已經學會了如何在你的應用程式中實現一個強大的 RBAC 系統。

對於更複雜的場景，例如構建多租戶應用程式，Logto 提供了完善的組織支持。查看我們的指南 構建多租戶 SaaS 應用程式：從設計到實現的完整指南，了解有關實施組織範圍存取控制的更多信息。

祝你編碼愉快！🚀