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