一個服務(wù)剛上線沒用戶沒登錄。調(diào)用方都是內(nèi)部系統(tǒng)相互信任——IP 白名單就夠了。后來用戶來了。要區(qū)分誰是誰。再后來有管理員、有普通用戶、有只讀用戶。角色一多權(quán)限判斷就散在代碼里——if user.role admin寫了二十遍改一次要改二十個文件。這時候你才開始看認(rèn)證鑒權(quán)方案。不是看誰文檔最全是看你的場景卡在哪一層。認(rèn)證和鑒權(quán)先分清認(rèn)證Authentication回答「你是誰」——登錄、驗證身份、確認(rèn)對面是本人。鑒權(quán)Authorization回答「你能做什么」——查權(quán)限、判角色、決定這個請求能不能過。先認(rèn)證身份再查權(quán)限。認(rèn)證在前鑒權(quán)在后。兩件事混在一起改一個影響另一個——分開就各管各的。認(rèn)證Session vs JWT傳統(tǒng) Session最直覺的做法用戶登錄成功后服務(wù)端生成一個 session 存 Redis 里返回一個 cookie。下次請求帶 cookie服務(wù)端查 Redis 找對應(yīng)的 session找到就知道是誰?？蛻舳?→ 登錄 → 服務(wù)端生成 session → 存 Redis → 返回 cookie 下次請求 → 帶 cookie → 服務(wù)端查 Redis → 找到 session → 通過夠簡單。服務(wù)端控制一切——session 丟了立馬清權(quán)限改了立馬生效。但代價在狀態(tài)。每個請求都要查一次 RedisRedis 掛了所有用戶掉線。擴(kuò)到多實例每個實例都要訪問同一個 Redis延遲加一跳。防 CSRF 要自己加 token防 session 劫持要設(shè) HttpOnly、Secure。JWTJWT 換了個思路不存狀態(tài)把用戶信息直接編碼進(jìn)一個 token 里。服務(wù)端簽發(fā)——簽了名改不了。客戶端帶著 token 來服務(wù)端驗簽名驗完直接用里面的信息不用查任何中央存儲。JWT 分三段Header用什么算法、Payload用戶 ID、過期時間、角色、Signature前兩段用密鑰簽名。三段用.連起來對機(jī)器是個字符串對人是個長串。Header.Payload.SignatureJWT 的好處是無狀態(tài)。任何實例都能驗——不用查 Redis不用查數(shù)據(jù)庫。擴(kuò)縮容跟它無關(guān)。微服務(wù)之間傳身份一個 JWT 就夠了——A 服務(wù)調(diào) B 服務(wù)把 JWT 帶上B 自己驗不用問 A「這人是誰」。JWT 的代價是沒法主動失效。簽出去了在過期時間之前服務(wù)端想讓它失效——做不到。token 在客戶端手里服務(wù)器沒任何辦法讓它提前作廢。要失效只能靠黑名單——每次請求查一遍黑名單——等于又回到中心存儲。JWT 把「無狀態(tài)」換成了「沒法主動控制」。JWT 最典型的踩坑把權(quán)限放 payload 里。Payload 是 Base64 編碼不是加密——任何人拿到 token 都能解碼看到里面內(nèi)容。把roleadmin放 payload安全。把permissionread_all_financial_data放 payloadtoken 一泄露權(quán)限全暴露。JWT 里的信息是公開的——不是加密是簽名。簽名的意義是「沒人能改」不是「沒人能看」。怎么選單服務(wù)、在乎實時控制、不介意查 Redis——Session。簡單可控要失效隨時失效。單體應(yīng)用天然選它。微服務(wù)、多實例、不想每次都查中心存儲——JWT。無狀態(tài)服務(wù)間傳身份方便。但要接受 token 沒法主動失效。既要無狀態(tài)、又要能失效——JWT 短過期 Refresh Token。JWT 設(shè) 15 分鐘過期過期了用 Refresh Token 換新的。Refresh Token 存在服務(wù)端能隨時吊銷——長期狀態(tài)的主動權(quán)還在服務(wù)端手里。鑒權(quán)從代碼到模型身份確認(rèn)了接下來是權(quán)限。權(quán)限有四種模型不是誰比誰好是看你的關(guān)系復(fù)雜到什么程度。RBAC最直接的RBAC 是 Role-Based Access Control——角色 權(quán)限。用戶有角色角色有權(quán)限權(quán)限控制操作。中間加了一層角色用戶和權(quán)限就不直接耦合了。用戶 → 角色 → 權(quán)限 → 資源三個角色管理員、編輯、只讀管幾百個用戶——改權(quán)限只改角色不用一個個用戶改。大部分系統(tǒng)用 RBAC 就夠了。但 RBAC 的問題是到不了資源級?！妇庉嬆芨奈恼隆埂哪钠衅?。「管理員能看數(shù)據(jù)」——看哪個表的所有表。RBAC 是資源類型級的——能改文章不能改某篇特定的文章。一旦需要「這個用戶只能看他所在部門的訂單」RBAC 就裝不下——要加屬性。ABAC把屬性加進(jìn)去ABAC 是 Attribute-Based Access Control——不只看角色還看屬性。用戶部門銷售 資源訂單 操作讀 環(huán)境內(nèi)網(wǎng)→ 允許不是「銷售能看訂單」是「銷售能看他自己部門的訂單」。屬性把權(quán)限從類型級縮小到實例級。但 ABAC 的代價是復(fù)雜度。屬性多了規(guī)則就多——用戶的部門、資源的所有者、操作的時間、環(huán)境的 IP、當(dāng)前的時間段。五六個維度交叉一條規(guī)則寫錯要么攔不住要么全攔住。而且規(guī)則多了排查困難——一個用戶被拒了不知道是哪條規(guī)則拒絕的。RBAC 的審計是「這個用戶是什么角色」ABAC 的審計是「這二十條規(guī)則哪條生效了為什么」。ACL最細(xì)但最重ACL 是 Access Control List——每條資源直接掛權(quán)限列表。文件 A用戶 1 可讀用戶 2 可寫用戶 3 不可見 文件 B用戶 1 可寫用戶 2 不可見ACL 的粒度是資源級的但管理成本是用戶級。一百萬個文件每個文件都要掛權(quán)限——改一個人要翻遍所有文件。RBAC 的用戶變了角色角色自動生效ACL 的用戶變了權(quán)限要一個個資源改。ACL 適合資源少、用戶少、但粒度要精確的場景——文件系統(tǒng)、云存儲桶策略。不適合用戶多、資源多的場景——管理成本隨資源數(shù)線性增長。怎么選角色多、但權(quán)限不精細(xì)到具體資源——RBAC。簡單夠用大部分系統(tǒng)的答案。權(quán)限要精細(xì)到具體資源、具體場景——ABAC。但要接受規(guī)則復(fù)雜度——規(guī)則多了排查和審計都難。上 ABAC 之前先問你真的需要這么細(xì)嗎還是 RBAC 加幾個if就能解決資源少、用戶少、但每個資源的權(quán)限都不同——ACL。云存儲、文件系統(tǒng)、K8s RBAC 背后實際是 ACL。剛開始、不知道以后會不會復(fù)雜——先 RBAC。復(fù)雜了再往上加屬性。不要一上來就 ABAC。OAuth 2.0不是認(rèn)證是授權(quán)一個常見誤解OAuth 2.0 是登錄。其實不是。OAuth 2.0 是委托授權(quán)——允許第三方應(yīng)用代表你去訪問你的資源但資源在你手里不在第三方手里?！赣?Google 登錄」Google 告訴這個網(wǎng)站我是誰 → 這是 OIDC 「允許這個 App 讀我的郵件」我授權(quán)這個 App 去 Google 拿我的數(shù)據(jù) → 這是 OAuth 2.0OIDCOpenID Connect才是身份認(rèn)證——建在 OAuth 2.0 上面的一個薄層。OAuth 2.0 負(fù)責(zé)授權(quán)OIDC 負(fù)責(zé)認(rèn)證——OIDC 在 OAuth 返回的 token 里多加了一個 ID Token告訴調(diào)用方「這個人是誰」。OAuth 2.0 的四種模式OAuth 2.0 別當(dāng)「一種協(xié)議」記當(dāng)「四種模式」——每種對應(yīng)不同場景。Authorization Code授權(quán)碼模式用戶→瀏覽器→授權(quán)服務(wù)器→返回授權(quán)碼→后端拿授權(quán)碼換 token。服務(wù)器對服務(wù)器你的后端和 Google 的后端在通信。最安全因為 token 不經(jīng)過瀏覽器。Client Credentials客戶端憑證模式服務(wù)對服務(wù)沒有用戶——后端直接拿 client_id client_secret 換 token。微服務(wù)之間的認(rèn)證。不是登錄是「這個服務(wù)確認(rèn)自己是自己」。Implicit隱式模式已廢棄。token 直接返回給瀏覽器——太暴露了URL 和 referrer 都可能泄露。Password密碼模式也被廢棄。用戶名密碼直接交給第三方——第三方完全可以記錄你的密碼。選 OAuth 模式不是選哪個好——是選「用戶在場還是不在場」「瀏覽器參與還是不參與」。有用戶、有瀏覽器——Authorization Code。沒用戶、只有服務(wù)間——Client Credentials。都不要用密碼模式——那是把自己密碼交給別人信任太強(qiáng)了。怎么選整體看回過頭看不是比誰的協(xié)議更完善是搞清楚你現(xiàn)在的需求卡在哪一層。先分清你在選認(rèn)證還是鑒權(quán)。認(rèn)證是「誰在敲門」鑒權(quán)是「門開了之后你能去哪」。兩個問題兩套方案。單體應(yīng)用、用戶不多、內(nèi)部系統(tǒng)——Session RBAC。簡單好排查改權(quán)限立馬生效。微服務(wù)、跨服務(wù)調(diào)用、不想每個請求都查中心——JWT OAuth 2.0 Client Credentials。服務(wù)間傳 JWT服務(wù)自己驗。對外開放、讓第三方訪問用戶數(shù)據(jù)——OAuth 2.0 Authorization Code。不要自己造輪子用 Keycloak、Casdoor、Authentik。OAuth 是趟過的路坑都在協(xié)議里修過了。權(quán)限精細(xì)到具體資源、具體場景——ABAC。但要接受規(guī)則復(fù)雜度的代價——規(guī)則多了排查難。大部分場景 RBAC 加幾個if就夠。已經(jīng)在云上、不想自己搭認(rèn)證服務(wù)器——云廠商的 IAMAWS IAM、阿里云 RAM。云廠商替你管用戶、管權(quán)限你自己只管策略。開源、自建、想控制一切——Keycloak。OIDC OAuth 2.0 SAML 全支持自帶 UI用戶管理不用自己寫。缺點是要自己運(yùn)維——多部署一個服務(wù)就多一個要監(jiān)控、備份、升級的東西。最后一條不要在代碼里散落權(quán)限判斷。if user.role admin寫一次沒事寫二十次就是安全漏洞——漏改一個要么權(quán)限不夠要么權(quán)限太寬。權(quán)限判斷收斂到一處中間件、網(wǎng)關(guān)、或策略引擎改了全部生效。代碼里散著的權(quán)限判斷不是邏輯是負(fù)債。