在前幾天，我們介紹了 Authentication（認證），重點在於「確認使用者是誰」。

接下來，我們要進入 Authorization（授權） 的領域，這是 Spring Security 的另一個核心功能。

如果說 Authentication 是「刷卡進大樓大門」，那麼 Authorization 就是「你能不能搭電梯到 20 樓？能不能進入會議室？」。

一、Authorization 的核心意義

Authorization 代表 系統判斷某個已認證使用者是否擁有執行特定操作的權限。

常見的檢查條件包含：

• 角色（Role）：例如 ROLE_ADMIN、ROLE_USER。
• 權限（Authority/Permission）：更細的資源控制，例如 READ_REPORT、WRITE_REPORT。
• 條件式規則：如「只能修改自己建立的資料」。

二、Spring Security 中的授權模型

Spring Security 的授權判斷通常有三個層級：

1. URL 層級（Filter-based）
   • 在 HttpSecurity 的設定中，透過 .requestMatchers() + .hasRole() 或 .hasAuthority() 來限制 API 訪問。
   • 適合大範圍規則，例如 /admin/** 僅限 ADMIN 使用。
2. 方法層級（Method-based）
   • 透過註解控制，例如：
     • @PreAuthorize("hasRole('ADMIN')")
     • @PostAuthorize("returnObject.owner == authentication.name")
   • 適合商業邏輯需要更精細的情境。
3. 資料層級（Domain/Object-based）
   • 透過 AccessDecisionVoter 或 ACL (Access Control List) 做到物件級的授權控制。
   • 例如：A 使用者能讀取「自己的」訂單，但不能讀取 B 使用者的訂單。

三、Role 與 Authority 的差異

在 Spring Security 中，常會看到 ROLE_USER 與 hasAuthority("READ_PRIVILEGE") 的用法，兩者有些細微差別：

實務上：

• Role 比較適合做大方向的授權（如系統功能模組）。
• Authority 則用於細緻控制（如 CRUD 操作）。

四、授權的決策流程

Spring Security 在判斷 Authorization 時，大致上會經歷以下流程：

1. Filter 驗證：使用者帶 Token / Cookie 進來後，Spring Security 先確認 Authentication 狀態。
2. AccessDecisionManager：授權決策器會收集使用者的 Authorities 與當前資源的需求。
3. AccessDecisionVoter：投票機制決定是否允許存取（通常有 Affirmative、Consensus、Unanimous 策略）。
4. 授權成功或拒絕：若拒絕，回傳 403 Forbidden。

五、舉例：銀行系統場景

假設一個銀行系統有以下角色與需求：

• Customer：只能看自己的帳戶與交易紀錄。
• Staff：可以查看客戶資訊，但不能刪除。
• Admin：可以管理系統，包含新增/刪除帳戶。

在 Spring Security 中可能會有以下配置：

• /account/** → hasRole("CUSTOMER") or hasRole("STAFF")
• /admin/** → hasRole("ADMIN")
• @PreAuthorize("#account.owner == authentication.name") → 確保客戶只能看自己的帳戶

六、結語與下一步

Authorization 的核心是 確保「正確的人」只能做「正確的事」。

它不僅僅是技術實作，更牽涉到系統安全策略的設計。

在接下來的章節，我們會深入探討 Spring Security 如何在程式碼中整合授權，包含 URL 層級與方法層級的設定，並示範常見的實作模式。

因為是新的概念，今天用比較斷點，一步一步的方式讓大家理解，那麼今天就分享到這裡，我們明天見囉！