角色為基礎的存取控制 (RBAC) 完整指南：掌握許可權設計、角色管理和安全授權，並提供實用的 CMS 實施示例。
你是否正在為實現一個安全和可擴展的授權系統而苦惱？角色為基礎的存取控制 (RBAC) 是管理用戶許可權的行業標準，但要正確地實施它可能很具挑戰性。本教程將向你展示如何使用一個實際的內容管理系統 (CMS) 示例來構建一個強健的 RBAC 系統。
透過遵循本指南，你將學到：
此教程的完整源代碼可在 GitHub 上獲得。
角色為基礎的存取控制不僅僅是給用戶分配許可權。它是關於創建一個結構化的授權方法，平衡安全性與可維護性。
你可以在 Auth Wiki 了解更多關於 RBAC 是什麼。
以下是我們將在實施中遵循的關鍵原則：
精細化的許可權讓你對用戶可以在系統中做什麼擁有精確的控制。與其使用如「管理員」或「用戶」這樣的廣泛訪問級別，我們定義用戶可以執行在資源上的具體動作。例如：
read:articles - 查看系統中的任何文章create:articles - 創建新文章update:articles - 修改現有文章publish:articles - 更改文章的發布狀態資源所有權是我們 CMS 授權設計中的基本概念。雖然 RBAC 定義了不同角色可以執行的動作，但所有權為訪問控制增加了一個個人層面：
update:articles 許可權，作者仍然可以編輯自己的文章這種雙層方法（角色 + 所有權）創造了一個更直觀和安全的系統。出版商和管理員仍然可以通過其角色許可權管理所有內容，而作者則保持對自己作品的控制。
讓我們從設計我們 CMS 的核心功能通過其 API 端點開始：
對於每個端點，我們需要考慮訪問控制的兩個方面：
這是我們將如何處理每個端點的訪問控制：
| 端點 | 訪問控制邏輯 |
|---|---|
| GET /api/articles | - 任何擁有 list:articles 許可權的人，或作者可以查看他們自己的文章 |
| GET /api/articles/:id | - 任何擁有 read:articles 許可權的人，或文章的作者 |
| POST /api/articles | - 任何擁有 create:articles 許可權的人 |
| PATCH /api/articles/:id | - 任何擁有 update:articles 許可權的人，或文章的作者 |
| DELETE /api/articles/:id | - 任何擁有 delete:articles 許可權的人，或文章的作者 |
| PATCH /api/articles/:id/published | - 只有擁有 publish:articles 許可權的用戶 |
根據我們的 API 訪問要求，我們可以定義這些許可權：
| 許可權 | 描述 |
|---|---|
| list:articles | 查看系統中所有文章的列表 |
| read:articles | 閱讀任何文章的完整內容 |
| create:articles | 創建新文章 |
| update:articles | 修改任何文章 |
| delete:articles | 刪除任何文章 |
| publish:articles | 更改發布狀態 |
注意，這些許可權僅在訪問你不擁有的資源時需要。文章所有者可以自動：
read:articles）update:articles）delete:articles）現在我們已經定義了 API 和許可權，我們可以創建將這些許可權邏輯分組的角色：
| 許可權/角色 | 👑 管理員 | 📝 出版者 | ✍️ 作者 |
|---|---|---|---|
| 描述 | 對整個內容管理系統的完全訪問 | 可以查看所有文章並控制發布狀態 | 可以在系統中創建新文章 |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
注意：無論角色許可權如何，作者自動擁有他們自己的文章的查看/更新/刪除許可權。
每個角色都設計有特定的責任：
此角色結構創造了明確的職責分工：
在開始之前，你需要在 Logto Cloud 創建一個帳戶，或者你可以使用 Logto OSS 版本 自行托管 Logto。
但對於本次教程，我們將使用 Logto Cloud 以簡化過程。
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
在 Logto 控制台中的「角色」頁面創建 CMS 的以下角色
read:articles, list:articles, publish:articlescreate:articles
進入 Logto 控制台的「用戶管理」部分創建用戶。
在用戶詳細信息的「角色」選項卡中，你可以將角色分配給用戶。
在我們的例子中，我們創建了3個用戶，具有以下角色：
現在，我們已經在 Logto 中設置了 RBAC，我們可以開始將其整合到我們的前端中。
首先，按照 Logto 快速入門 的步驟，將 Logto 整合進入你的應用程式。
在我們的例子中，我們使用 React 進行演示。
在你的應用程式中設置 Logto 之後，我們需要添加 RBAC 配置以使 Logto 工作。
如果你已經登錄，請記得登出並重新登錄，使更改生效。
當用戶使用 Logto 登錄並請求上述指定的 API 資源的訪問權杖時，Logto 將根據用戶角色添加相關的範疇（許可權）到訪問權杖。
你可以使用 useLogto 鉤子中的 getAccessTokenClaims 來獲取訪問權杖中的範疇。
你可以使用 userScopes 來檢查用戶是否有權訪問資源。
現在，是時候將 Logto RBAC 與後端整合了。
首先，我們需要在後端添加一個中介軟體來檢查用戶許可權，確認用戶是否已登入，並確定他們是否擁有訪問特定 API 所需的許可權。
如你所見，在這個中介軟體中，我們驗證前端請求是否包含有效的訪問權杖，並檢查訪問權杖的受眾是否與我們在 Logto 控制台中創建的 API 資源匹配。
驗證 API 資源的原因是因為我們的 API 資源實際上代表了我們 CMS 後端的資源，並且我們所有的 CMS 許可權都與此 API 資源相關聯。
由於這個 API 資源代表了 Logto 中的 CMS 資源，在我們的前端代碼中，我們在向後端發出 API 請求時包括相應的訪問權杖：
現在我們可以使用 requireAuth 中介軟體來保護我們的 API 端點。
對於只能由具有特定許可權的用戶訪問的 API，我們可以直接在中介軟體中添加限制。例如，文章創建 API 應該只能由具有 create:articles 許可權的用戶訪問：
對於需要同時檢查許可權和資源所有權的 API，我們可以使用 hasScopes 函數。例如，在文章列表 API 中，具有 list:articles 許可權的用戶可以訪問所有文章，而作者可以訪問他們自己創建的文章：
至此，我們已經完成了 RBAC 的實現。你可以查看 完整的源代碼 以查看完整的實現。
現在，讓我們使用剛剛創建的三個用戶測試我們的 CMS RBAC 實現。
首先，讓我們分別以 Alex 和 Charles 的身份登錄並創建一些文章。
由於 Alex 擁有管理員角色，他可以創建、刪除、更新、發布和查看所有文章。
Charles 擔任作者角色，可以僅創建自己的文章，並且僅能查看、更新、和刪除他們擁有的文章。
Bob 擁有出版者角色，可以查看和發布所有文章，但不能創建、更新或刪除它們。
恭喜你！你已學會如何在你的應用程式中實現一個強健的 RBAC 系統。
對於更複雜的場景，如構建多租戶應用程式，Logto 提供了全面的組織支持。查閱我們的指南 構建多租戶的 SaaS 應用程式：從設計到實施的完整指南 以了解更多關於實現企業級訪問控制的資訊。
祝編程愉快！🚀