開始
許可權系統無非是解決兩個問題，Authentication（認證-你是誰）和 Authorization（授權-你能幹什麼）。
Authentication
認證的問題，很好理解，就是根據使用者的身份憑據，計算出這個使用者的身份資訊。
而身份憑據，常見有 Token 和 Session，還有 Permanent Token（永久令牌）、Application password（應用專用密碼）等。
這裡可以延伸聊一下登入問題，其實登入不應該算作 Authentication 範疇，登入只是一個 Action，用於換取身份憑據的動作。沒有登入這個工作，換種方式頒發身份憑據，難道許可權系統就不能工作了嗎？
Authorization
Authorization 又可以劃分為三個問題來解決：
- 分配：賦予誰什麼許可權；
- 解決/計算：計算誰有什麼許可權；
- 判斷：判斷誰是否有某個許可權；
分配
分配要考慮的問題有兩個，一個是誰、一個是目標。因此分配要解決的問題就是：要給誰在什麼目標上分配什麼許可權。
給誰？比如使用者、使用者組等，我們稱為 Owner。
什麼目標？許可權分配一定要有一個附著點，比如專案、公司、組織等，我們稱為 AuthTarget 。
什麼許可權？為了分配上的方便，我們常常把一堆許可權集稱為 角色，角色的作用僅僅是為了分配上的簡潔，一般不用來做判斷，什麼原因，下文會解釋。
我們一般推薦許可權系統是模組獨立於業務系統的，很簡單，許可權系統本來就是業務不相關的。我們只要將許可權系統的 AuthTarget 和業務系統的資源做關聯，就能驅動業務系統完成許可權工作，而這個關聯行為是許可權系統關聯業務系統，還是業務系統關聯許可權系統，或是單獨關聯，仁者見仁，智者見智。
解決
計算一個 Owner 有什麼許可權，並快取起來。
這點主要是為了效能的考慮，如果在判斷的時候再去計算 Owner 的許可權，必將大大拖累業務系統的效能，而且一個 Owner 的許可權大部分時間內都是不變的，因此快取命中率特別高，特別適合快取。
快取的 Key 的是 Owner，Value 包括 許可權 + AuthTarget。
判斷
判斷一個 Owner 是否有許可權訪問資源。
判斷分為前端和後端，而判斷的前提就是依賴 解決 中快取的使用者許可權。
為什麼不用 角色 來判斷 Owner 是否能訪問資源呢？如果諸多資源都用一個角色 判斷，不方便擴充套件和拆分，更嚴重的是，隨著時間推移，常常出現自己都預想不到的越權行為，因為到處都是基於某個角色的判斷。那麼我多定義一些角色呢？額。這不就變成了許可權判斷？
直接使用許可權進行判斷，可以為使用者提供更精細的許可權控制。安全系統設計的一個重要原則是“最小許可權原則”（Principle of Least Privilege），即應儘可能只授予使用者完成任務所需的最低許可權。透過直接基於許可權判斷，可以更加嚴格地控制使用者許可權的分配，減少誤授權的可能性。