實踐中的 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 控制台中的「應用程式」頁面創建一個新的反應應用程式
   • 應用程式名稱：內容管理系統
   • 應用程式類型：傳統網絡應用程式
   • 重定向 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 之後，我們需要添加 RBAC 配置以使 Logto 工作。

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

當用戶使用 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 應用程式：從設計到實施的完整指南 以了解更多關於實現企業級訪問控制的資訊。

祝編程愉快！🚀