前言

前面的文章大多在說明 Authentication（認證）：系統如何透過密碼、MFA、Passkey、OAuth 或 OIDC，確認目前提出請求的是哪一個身分。

但使用者成功登入後，系統還要回答另一個問題：這個身分可以執行哪些操作？ 這屬於 Authorization（授權）的範圍。

本篇會先釐清 Authentication 與 Authorization 的差異，再介紹最常見的存取控制模型之一：RBAC（Role-Based Access Control，角色型存取控制）。RBAC 不會直接替每位使用者逐一設定權限，而是先將 Permission 整理成 Role，再把 Role 指派給 User。

今天內容涵蓋：

1. Authentication 與 Authorization 的差異
2. Authorization 如何做出 Allow／Deny 決定
3. 為什麼不適合直接替每位 User 設定 Permission
4. RBAC 如何透過 Role 管理 Permission
5. RBAC 可以加入哪些進階規則
6. 多租戶 SaaS 的 RBAC 設計
7. RBAC 的限制與 Role Explosion
8. Token 如何傳遞 RBAC 資訊

一、Authentication 與 Authorization 的差異

Authentication 與 Authorization 都會影響使用者能否繼續操作，但兩者處理的問題不同：

例如，員工使用 Passkey 登入公司系統，是在完成 Authentication；登入後開啟薪資頁面時，系統還要確認該員工是否具有讀取薪資的 Permission，這一步才是 Authorization。

⚠️ Authenticated ≠ Authorized。 通過身分驗證，只代表系統知道目前是誰，不代表這個身分可以執行所有操作。

二、Authorization 如何做出 Allow／Deny 決定

一次 Authorization 判斷，通常可以拆成四個基本元素：

• Subject： 誰提出操作，例如 Gloria、某個 Service Account 或後端服務。
• Resource： 要存取什麼，例如薪資資料、Repository、訂單或 API。
• Action： 要執行什麼，例如 Read、Create、Update 或 Delete。
• Policy／Permission： 系統依據哪些規則允許或拒絕操作。

因此，Authorization 實際要判斷的是：「某個 Subject 是否可以對指定的 Resource 執行某項 Action？」例如：

• Gloria 是否可以讀取薪資資料？
• Joanne 是否可以修改系統設定？

系統會先確認 Subject，再取得這個 Subject 具有的 Permission，最後根據 Resource、Action 與相關 Policy 做出 Allow 或 Deny 決定。

Authentication 解決的是「誰正在操作」；Authorization 解決的則是「這個身分可以碰哪些資源、執行哪些動作」。

三、為什麼不適合直接替每位 User 設定 Permission

最直覺的做法，是直接替每位使用者勾選 Permission：

人數很少時，這種方式看起來沒有問題；但使用者增加後，管理成本會迅速上升：

• 新人到職： 必須重新勾選一整組 Permission，容易遺漏或設定錯誤。
• 職務調動： 除了加入新權限，還要記得收回舊職務的權限。
• 規則重複： 擔任相同職務的人，仍要各自維護一份相同設定。
• 稽核困難： 若要查出「目前誰可以讀取薪資」，必須逐一檢查所有使用者。

問題不在 Permission 本身，而是 User 與 Permission 被直接綁在一起。RBAC 會在兩者之間加入 Role，將「誰擔任這個職務」與「這個職務能做什麼」分開管理。

四、RBAC 如何透過 Role 管理 Permission

RBAC 會把 User 與 Permission 的關係拆成兩個部分：

1. Role → Permission： 先定義每個角色可以執行哪些操作。
2. User → Role： 再把適合的角色指派給使用者。

兩者合起來，就是 RBAC 最核心的關係：User → Role → Permission。

第一步：定義 Role 可以做什麼

沿用第三節的例子，可以先建立以下 Role：

第二步：把 Role 指派給 User

接著再依照職務分配 Role：

Gloria 與 Joanne 不需要各自維護一份相同的權限，只要同時被指派 HR Role 即可。日後若公司決定 HR 不得再修改請假單，也只需要調整 HR Role；所有擁有該 Role 的使用者都會套用新的設定。

這就是 Role 作為中間層的作用：User 的職務發生變動時調整 Role；某項職務的權限發生變動時調整 Permission。

設計 RBAC 的基本順序

仍以同一個公司系統為例，可以依序進行：

1. 找出需要保護的 Resource： 薪資資料、請假單、系統設定。
2. 列出允許的 Action： 讀取、修改或管理。
3. 組合成 Permission： 例如 payroll:read、leave:update、system:configure。
4. 建立 Role： 將相關 Permission 分配給 HR、Engineer 或 System Administrator。
5. 指派 User： 最後再把 Gloria、Joanne、Kevin 與 Mark 指派到對應的 Role。

設計 Role 時還要遵循最小權限原則：每個 Role 只包含完成職務所需的 Permission，避免為了方便而授予過大的權限。

🔗 Kubernetes 的 RBAC 就是這套關係的實際例子。User、Group 或 ServiceAccount 會先透過 RoleBinding 取得 Role，再由 Role 裡的 resources 與 verbs 決定可以操作哪些資源。實際設定方式可參考 Day 24｜RBAC — Kubernetes 的角色權限控制。

五、RBAC 可以加入哪些進階規則

前一節介紹的 User → Role → Permission，已經是最基本的 RBAC。當角色變多或操作涉及重要資料時，系統還可以加入兩種進階規則：角色繼承與職責分離。

角色繼承：上層 Role 自動包含下層 Role 的權限

假設 HR 與 HR Manager 都需要讀取薪資、修改請假單，而 HR Manager 還能核准薪資調整。如果沒有角色繼承，兩個 Role 就要重複設定相同的 Permission；加入繼承後，只需要讓 HR Manager 繼承 HR，再補上額外權限。

這樣調整 HR 的共通權限時，HR Manager 也會一併套用，不必維護兩份相同設定。

職責分離：避免同一個人掌握完整流程

有些操作不能只看「具不具有某個 Role」，還要避免權限過度集中。例如，提出採購申請的人不應同時核准自己的申請。系統可以將職責拆成兩個 Role：

• Requester： 可以建立及送出採購申請，但不能核准。
• Approver： 可以核准採購申請，但不能核准自己送出的申請。

這類限制稱為 Separation of Duty（SoD，職責分離），常用於財務、採購與其他需要稽核的流程。

將這些能力整理後，可以看到四種常見形式：

💡這四種形式不是每個系統都必須依序導入。一般系統可以先使用基礎 RBAC，確實遇到權限重複或職責衝突時，再加入角色繼承或職責分離。

六、多租戶 SaaS 的 RBAC 設計

在多租戶 SaaS 中，同一位使用者可能加入多個 Organization，並在每個 Organization 擔任不同角色。例如，Gloria 在 A 公司是 Admin，在 B 公司可能只是 Member。

常見設計會把 Role 分成兩個範圍：

實際落地時，常見以下三種模型：

模型一：以全域 Role 管理共用 API

這個模型不區分 Organization，Role 與 Permission 都直接定義在產品層級。圖中的關係由左至右分成三步：

1. User 或 M2M Application 先被指派一個或多個 Role。
2. 每個 Role 對應一組 Permission。
3. Permission 再指定可以操作哪一個 API Resource。

例如，Gloria 同時擁有 Cookie Shop Manager 與 Cookie Shop Admin，因此會合併兩個 Role 的 Permission，可以讀取、更新或刪除 Cookie 資料；Joanne 的 Customer 與 Guest Role 則對應訂單查詢權限。M2M Application 不代表真人，但同樣能透過 Service Agent Role 取得 create:order，呼叫訂單 API 建立訂單。

這裡的「全域」是指 Role 與 Permission 不綁定特定 Organization，並不表示所有 User 都能存取全部資料；每個 Subject 仍只能使用自己所屬 Role 提供的 Permission。

模型二：Organization 內部功能

每個 Organization 都有自己的 Role。判斷權限時，不能只看使用者是不是 Admin，還要看使用者在哪一個 Organization 擔任 Admin。

圖中的角色分配如下：

• Joanne 是 Cookie Shop A 的 Admin。
• Gloria 在 Cookie Shop A 是 Member，在 Cookie Shop B 是 Admin。
• M2M Application 是 Cookie Shop B 的 Member。

因此，Gloria 在兩間店可以使用的功能不同。圖中的 invite:staff 與 manage:billing，就是邀請員工與管理帳務等內部功能權限。

模型三：Organization 層級 API 資源

模型三與模型二的角色分配方式相同，差別是 Permission 會再連到實際的 API：

• invite:staff、delete:staff → Staff API
• manage:billing → Billing API

例如，Joanne 是 Cookie Shop A 的 Admin，所以只能使用 Cookie Shop A 的權限存取 API，不能用同一個 Role 操作 Cookie Shop B 的資料。

Resource Server 收到請求時，要一起檢查：

1. 是誰提出請求。
2. 正在操作哪一個 Organization。
3. 在該 Organization 具有哪個 Role。
4. 該 Role 是否具有操作目標 API 的 Permission。

七、RBAC 的限制：Role Explosion

RBAC 的優點在於管理集中、容易稽核，而且 Role 通常可以對應組織中的職務。新人到職、離職或調動時，只要調整 Role 指派即可。

但 RBAC 不擅長處理大量動態條件。例如：

• HR 只能在上班時間查閱薪資。
• Editor 只能編輯自己部門建立的文件。
• Manager 只能核准金額低於特定門檻的申請。

如果仍只用 Role 表達這些規則，就可能出現「HR－上班時間」「HR－唯讀」「HR－特定部門」等大量變形 Role。這種 Role 數量不斷增加、最後難以維護的情況，稱為 Role Explosion（角色爆炸）。

💡RBAC 適合表達相對穩定的職務權限；若規則高度依賴使用者、資源或環境屬性，通常需要再搭配 ABAC、ACL 或 ReBAC。

八、Token 如何傳遞 RBAC 資訊

在使用 Access Token 保護 API 的系統中，Token 可以攜帶 roles 或 scope，讓 Resource Server 知道目前的 Subject 具有哪些角色或存取範圍。例如：

{
  "sub": "usr_gloria",
  "aud": "payroll-api",
  "roles": ["HR"],
  "scope": "payroll:read leave:update"
}

這個範例表示 Token 代表 Gloria，目標是 Payroll API；roles 表示具有 HR Role，scope 則表示這顆 Token 可以要求讀取薪資與修改請假單。

收到請求後，Resource Server 會先驗證 Token，再讀取其中的 Claim，並確認目前的 Role 或 Scope 是否包含操作目標 Resource 所需的 Permission。

Role 與 Scope 的用途不同：Role 表示 Subject 在系統中的角色；Scope 表示這顆 Token 被允許使用的範圍。兩者都只是授權判斷的依據，最後仍由 Resource Server 根據目標 Resource、Action 與 Policy 決定 Allow 或 Deny。

小結

RBAC 的核心，是在 User 與 Permission 之間加入 Role，避免逐一維護每個人的權限。

本篇可以整理成以下幾個重點：

• Authentication 用來確認身分；Authorization 用來決定該身分可以操作哪些 Resource。
• RBAC 的基本關係是 User → Role → Permission，Role 集中管理一組相關權限。
• 多租戶 SaaS 還要確認 Role 所屬的 Organization，避免使用同一個 Role 存取其他租戶的資料。
• 角色繼承與職責分離可以處理較複雜的組織規則；如果權限高度依賴時間、部門或資源屬性，單靠 RBAC 則可能造成 Role Explosion。
• Access Token 可以攜帶 Role 或 Scope，但最終仍由 Resource Server 根據實際請求執行授權檢查。

下一篇將介紹 ABAC（Attribute-Based Access Control，屬性型存取控制），說明系統如何根據使用者、資源與環境條件，建立比固定 Role 更細緻的授權規則。

參考資源

• What is Role-based access control (RBAC)?－Auth Wiki
• Role-based access control (RBAC)－Logto Docs
• Role-Based Access Control (RBAC)－NIST CSRC
• Role-Based Access Control (RBAC): A Comprehensive Guide－Pathlock
• 角色型存取控制（RBAC）：打造安全且高效率的驗證體驗－Authgear
• 什麼是基於角色的存取控制（RBAC）？－Cloudflare
• RBAC 和 ABAC：你應該了解的存取控制模型－Logto Blog
• RBAC vs ABAC: 7 Key Differences Explained－Ory
• Authentication vs. Authorization－Auth0 Docs