1. 項目概述為什么我們需要盤點登錄與鑒權(quán)框架做后端開發(fā)或者全棧開發(fā)的朋友對“登錄”和“鑒權(quán)”這兩個詞一定不陌生。這幾乎是每個帶用戶系統(tǒng)的應(yīng)用都無法繞開的基石。簡單來說“登錄”解決的是“你是誰”的問題而“鑒權(quán)”則是在你表明身份后判斷“你能干什么”。聽起來簡單但真要自己從零開始實現(xiàn)一套安全、健壯、可擴展的認證授權(quán)體系里面的坑多到能讓你懷疑人生。從最基礎(chǔ)的密碼存儲加鹽哈希是必須的、Session管理分布式下怎么辦到復(fù)雜的單點登錄SSO、OAuth2.0第三方授權(quán)、細粒度的權(quán)限控制RBAC/ABAC每一個環(huán)節(jié)都需要深思熟慮。正因為其復(fù)雜性和安全性要求極高社區(qū)里涌現(xiàn)出了一大批優(yōu)秀的開源框架來幫助我們解決這些問題。它們封裝了那些繁瑣、易錯的安全細節(jié)讓我們能更專注于業(yè)務(wù)邏輯。但框架多了選擇也成了難題。Spring Security 功能強大但學(xué)習(xí)曲線陡峭Apache Shiro 輕量簡潔但在微服務(wù)場景下可能力不從心新興的sa-token以設(shè)計優(yōu)雅著稱……每個框架都有自己的設(shè)計哲學(xué)和適用場景。所以這次我想結(jié)合自己這些年踩過的坑和項目經(jīng)驗系統(tǒng)地盤點一下那些主流的、在Java生態(tài)中活躍的開源登錄及權(quán)限認證框架。這不是一份簡單的功能列表對比我會深入到它們的核心設(shè)計、適用場景、上手成本以及那些官方文檔里不會寫的“坑”。無論你是正在為技術(shù)選型糾結(jié)的架構(gòu)師還是想深入理解認證授權(quán)原理的開發(fā)者希望這篇內(nèi)容都能給你帶來實實在在的參考價值。2. 核心概念掃盲認證、授權(quán)、鑒權(quán)與權(quán)限在深入框架之前我們必須先統(tǒng)一“語言”。很多人容易混淆認證、授權(quán)、鑒權(quán)這些術(shù)語雖然它們緊密相關(guān)但職責(zé)分明。理解這些概念是看懂框架設(shè)計的前提。2.1 認證證明你是你認證的英文是 Authentication核心目標是驗證主體的身份是否屬實。這個“主體”通常是用戶也可以是設(shè)備、服務(wù)等。最常見的例子就是用戶名密碼登錄。系統(tǒng)核對用戶名和密碼是否正確這個過程就是認證。認證成功后系統(tǒng)會為你創(chuàng)建一個“身份憑證”比如一個 Session ID 或者一個 Token如 JWT在后續(xù)的請求中你出示這個憑證系統(tǒng)就知道你是誰了。注意認證只關(guān)心“身份”的真實性不關(guān)心這個身份“能做什么”。比如你證明了你是公司員工可以進入大樓認證通過但你能進入哪個會議室、能查看哪些文件這不是認證管的事。2.2 授權(quán)與權(quán)限決定你能做什么授權(quán)的英文是 Authorization。它發(fā)生在認證之后核心目標是判斷一個已經(jīng)認證通過的主體是否有權(quán)限執(zhí)行某個操作或訪問某個資源。這里就引出了“權(quán)限”的概念。權(quán)限通常是對資源如API接口、菜單、按鈕、數(shù)據(jù)行的操作許可如讀、寫、刪除。常見的權(quán)限模型有RBAC基于角色的訪問控制。這是最流行的模型。權(quán)限不直接分配給用戶而是先分配給角色再把角色賦予用戶。例如“管理員”角色擁有“刪除用戶”的權(quán)限。用戶張三被賦予“管理員”角色他就間接擁有了“刪除用戶”的權(quán)限。這樣管理起來非常方便新增用戶只需分配角色即可。ABAC基于屬性的訪問控制。這是一種更動態(tài)、更細粒度的模型。權(quán)限決策不僅基于用戶角色還基于一系列屬性如用戶部門、資源標簽、操作時間、地理位置等。例如“允許部門經(jīng)理在工作時間9:00-18:00審批本部門的報銷單”。ABAC更靈活但實現(xiàn)和規(guī)則管理也更復(fù)雜。2.3 鑒權(quán)執(zhí)行授權(quán)檢查的動作鑒權(quán)這個詞在中文語境下有時會和授權(quán)混用但更精確地說鑒權(quán)是執(zhí)行授權(quán)檢查這個動作的過程。當(dāng)用戶請求一個需要權(quán)限的接口時系統(tǒng)攔截該請求根據(jù)當(dāng)前用戶的身份和權(quán)限規(guī)則判斷是否允許該請求通過。這個“判斷并執(zhí)行”的流程就是鑒權(quán)。我們常說的“權(quán)限攔截器”、“訪問決策管理器”干的就是鑒權(quán)的活。用一個生活化的類比來串聯(lián)一下你去圖書館系統(tǒng)。認證出示你的學(xué)生證用戶名密碼管理員核對照片和信息確認你是本校學(xué)生認證通過給你一張通行卡Session/Token。授權(quán)圖書館的規(guī)則規(guī)定權(quán)限模型普通學(xué)生可以借閱5本書研究生可以借閱10本教師可以進入珍本庫。這些規(guī)則就是授權(quán)策略。鑒權(quán)當(dāng)你拿著通行卡想去珍本庫時門口的閘機鑒權(quán)攔截器會讀取你的卡發(fā)現(xiàn)你的身份是“普通學(xué)生”而規(guī)則顯示“普通學(xué)生不可進入珍本庫”于是閘機不放行返回403 Forbidden。理解了這些我們再去看各個框架就會發(fā)現(xiàn)它們無外乎是在用不同的方式、不同的抽象層次來幫助我們實現(xiàn)這套流程。3. 主流開源框架深度解析上篇本系列的上篇我們將重點剖析三個在Java生態(tài)中歷史悠久、應(yīng)用廣泛的“巨頭”級框架Spring Security、Apache Shiro 和sa-token。我會從設(shè)計理念、核心架構(gòu)、優(yōu)缺點和典型使用場景來展開。3.1 Spring Security功能全面的“瑞士軍刀”如果你在使用Spring Boot那么Spring Security幾乎是你最先接觸到的安全框架。它不僅僅是登錄鑒權(quán)更是一個高度可定制、功能全面的安全框架。3.1.1 核心設(shè)計理念與架構(gòu)Spring Security 的核心是過濾器鏈。它將安全控制邏輯拆分成一系列職責(zé)單一的Filter串聯(lián)成一個鏈條。一個HTTP請求會依次通過這個鏈條每個過濾器負責(zé)一項具體的安全任務(wù)例如UsernamePasswordAuthenticationFilter: 處理表單登錄。BasicAuthenticationFilter: 處理HTTP Basic認證。FilterSecurityInterceptor: 進行最終的授權(quán)決策是鑒權(quán)的核心關(guān)口。它的另一大核心是SecurityContextHolder。這是一個線程綁定的存儲容器用于存放當(dāng)前已認證用戶的信息Authentication對象。一旦用戶登錄成功其Authentication對象就會被設(shè)置到SecurityContextHolder中在同線程的后續(xù)處理中可以隨時從中獲取當(dāng)前用戶信息。3.1.2 核心組件與配置Spring Security 的配置看似復(fù)雜但理解了幾個核心組件后就清晰了UserDetailsService: 這是連接你用戶數(shù)據(jù)庫的橋梁。你需要實現(xiàn)這個接口的loadUserByUsername方法告訴Spring Security如何根據(jù)用戶名查找用戶信息和權(quán)限。PasswordEncoder: 密碼編碼器。負責(zé)密碼的加密與比對。強烈推薦使用BCryptPasswordEncoder它每次加密都會生成隨機的鹽安全性遠高于MD5或SHA-256的簡單哈希。配置類 (EnableWebSecurity) 在這里通過重寫configure(HttpSecurity http)方法來定義安全規(guī)則。這是學(xué)習(xí)曲線最陡的部分但也是最強大的部分。Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/, /home, /login).permitAll() // 這些路徑允許所有人訪問 .antMatchers(/admin/**).hasRole(ADMIN) // /admin/ 下的路徑需要ADMIN角色 .antMatchers(/user/**).hasRole(USER) // /user/ 下的路徑需要USER角色 .anyRequest().authenticated() // 其他所有請求都需要認證 .and() .formLogin() .loginPage(/login) // 自定義登錄頁 .permitAll() .and() .logout() .permitAll(); } }3.1.3 優(yōu)勢與挑戰(zhàn)優(yōu)勢與Spring生態(tài)無縫集成這是它最大的優(yōu)勢。對于Spring項目它能天然地與其他組件如Spring Data JPA, Spring MVC協(xié)作。功能極其全面從基礎(chǔ)的登錄、注銷、Remember-Me到復(fù)雜的OAuth2.0、SAML、LDAP集成再到方法級安全PreAuthorize、ACL訪問控制列表幾乎涵蓋了企業(yè)級安全的所有需求。高度可定制基于過濾器鏈的設(shè)計允許你在任何環(huán)節(jié)插入自定義邏輯靈活性極高。挑戰(zhàn)與“坑”學(xué)習(xí)曲線陡峭初學(xué)者很容易被其復(fù)雜的配置和抽象概念如SecurityContextHolder,AuthenticationManager嚇退。官方文檔雖然詳盡但缺乏由淺入深的引導(dǎo)。配置繁瑣默認配置可能不符合你的需求而自定義配置需要深入理解其運行機制否則容易配置錯誤導(dǎo)致安全漏洞或功能異常。“太重”對于小型項目或微服務(wù)中的單個輕量級服務(wù)引入完整的Spring Security可能顯得有些臃腫。實操心得學(xué)習(xí)Spring Security不要試圖一開始就弄懂所有配置。從一個最簡單的、能跑通的例子開始然后逐步增加功能如自定義登錄頁、連接數(shù)據(jù)庫、添加角色控制。多利用調(diào)試模式觀察請求是如何經(jīng)過一個個過濾器的這對理解其工作原理有奇效。3.2 Apache Shiro簡單直接的“安全衛(wèi)士”與Spring Security的“重量級”和“侵入性”相比Apache Shiro 的設(shè)計哲學(xué)是簡單和直觀。它不依賴任何容器或框架可以運行在任何環(huán)境中。3.2.1 核心設(shè)計理念Shiro 的核心抽象非常簡潔圍繞三個核心概念Subject: 代表當(dāng)前執(zhí)行操作的用戶或程序。所有與安全相關(guān)的操作登錄、鑒權(quán)都是通過與Subject交互來完成。SecurityManager: Shiro 架構(gòu)的核心管理所有Subject負責(zé)認證、授權(quán)等所有安全操作。你可以把它看作是Shiro的“大腦”。Realm: 安全數(shù)據(jù)源。這是Shiro與你應(yīng)用的用戶、權(quán)限數(shù)據(jù)連接的地方。你需要自定義Realm來實現(xiàn)從數(shù)據(jù)庫、LDAP等地方獲取認證和授權(quán)信息。這種設(shè)計讓Shiro的API非常直觀subject.login(token),subject.hasRole(admin),subject.isPermitted(user:delete)。3.2.2 快速上手示例在Spring Boot中集成Shiro也非常簡單添加依賴(shiro-spring-boot-starter)。自定義Realm:public class MyShiroRealm extends AuthorizingRealm { Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { // 授權(quán)邏輯根據(jù)用戶名查詢角色和權(quán)限 String username (String) principals.getPrimaryPrincipal(); SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); info.addRole(user); // 添加角色 info.addStringPermission(article:read); // 添加權(quán)限字符串 return info; } Override protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { // 認證邏輯根據(jù)用戶名密碼驗證用戶 UsernamePasswordToken upToken (UsernamePasswordToken) token; String username upToken.getUsername(); // 從數(shù)據(jù)庫查詢用戶信息... User user userService.findByUsername(username); if (user null) { throw new UnknownAccountException(用戶不存在); } // 比對密碼 (Shiro會自動完成) return new SimpleAuthenticationInfo(user.getUsername(), user.getPassword(), getName()); } }配置Shiro過濾器在配置類中定義哪些路徑需要攔截哪些需要放行。3.2.3 優(yōu)勢與局限性優(yōu)勢API簡單易懂學(xué)習(xí)成本遠低于Spring Security。其核心概念幾分鐘就能理解。輕量級、無侵入不依賴Spring可以輕松集成到任何Java應(yīng)用中。功能夠用對于常見的認證、基于角色的授權(quán)、Session管理、加密等功能支持良好。局限性功能相對單一在OAuth2、SAML等現(xiàn)代協(xié)議支持上需要額外的集成或自行實現(xiàn)不如Spring Security原生支持得完善。微服務(wù)支持弱在分布式、無狀態(tài)的微服務(wù)架構(gòu)下Shiro原生的Session管理默認基于內(nèi)存會成為瓶頸。雖然可以通過集成Redis等實現(xiàn)分布式Session但這需要額外工作且生態(tài)不如Spring Session成熟。與Spring生態(tài)集成度雖然可以通過starter集成但在深度上如與Spring MVC注解的完美結(jié)合仍不如Spring Security原生。注意事項Shiro的權(quán)限字符串設(shè)計如user:delete:*非常靈活但需要你在業(yè)務(wù)層和Realm中維護好這套字符串規(guī)則。如果規(guī)則變得非常復(fù)雜管理起來會有些麻煩。對于中小型單體應(yīng)用或?qū)pring無強依賴的項目Shiro是一個優(yōu)雅而高效的選擇。3.3 Sa-Token面向現(xiàn)代設(shè)計的“新銳力量”sa-token是一個國產(chǎn)的輕量級Java權(quán)限認證框架。它誕生于Spring Security和Shiro廣泛使用的時代旨在解決它們在某些場景下的痛點特別是針對微服務(wù)和無狀態(tài)架構(gòu)。3.3.1 設(shè)計哲學(xué)與核心特性sa-token的設(shè)計口號是“簡單、強大”。它有幾個非常吸引人的特性注解式鑒權(quán)通過像SaCheckLogin,SaCheckRole(admin),SaCheckPermission(user:add)這樣的注解可以以極簡的方式完成方法級別的權(quán)限控制無需復(fù)雜配置。開箱即用的Token認證默認采用無狀態(tài)的Token類似JWT但可擴展作為認證憑證天然適合前后端分離和微服務(wù)。豐富的會話管理不僅支持內(nèi)存會話更原生支持集成 Redis 進行分布式會話管理解決微服務(wù)下的登錄狀態(tài)共享問題。踢人下線、賬號封禁內(nèi)置了諸如強制下線、禁用賬號等實用功能API調(diào)用非常簡單。3.3.2 極簡的代碼示例它的使用方式簡單到令人驚訝添加依賴。配置可選很多有默認值在application.yml中配置Token名稱、有效期、存儲類型等。sa-token: token-name: satoken # Token名稱 timeout: 2592000 # 有效期30天 active-timeout: -1 # 活躍期內(nèi)無操作則Token不會過期 is-concurrent: true # 是否允許同一賬號并發(fā)登錄 is-share: true # 在多人登錄同一賬號時是否共享同一個Token登錄與鑒權(quán)// 登錄 PostMapping(/login) public SaResult login(String username, String password) { // 1. 查詢數(shù)據(jù)庫驗證用戶... if(zhang.equals(username) 123456.equals(password)) { // 2. 登錄并返回Token StpUtil.login(10001); // 參數(shù)為用戶的唯一標識如userId return SaResult.ok(登錄成功).setData(StpUtil.getTokenValue()); } return SaResult.error(登錄失敗); } // 在需要權(quán)限的方法上添加注解 SaCheckLogin // 檢查是否登錄 GetMapping(/user/info) public SaResult getInfo() { long userId StpUtil.getLoginIdAsLong(); // 獲取當(dāng)前登錄用戶ID // ... 業(yè)務(wù)邏輯 return SaResult.data(userInfo); } SaCheckRole(admin) // 必須擁有admin角色 PostMapping(/user/delete) public SaResult deleteUser(Long id) { // ... 刪除用戶邏輯 return SaResult.ok(); }3.3.3 優(yōu)勢與適用場景分析優(yōu)勢API設(shè)計極其友好學(xué)習(xí)成本極低開發(fā)者心智負擔(dān)小。注解鑒權(quán)的方式讓代碼非常清晰。對微服務(wù)/前后端分離支持好無狀態(tài)Token、分布式會話、服務(wù)網(wǎng)關(guān)鑒權(quán)等特性都是為現(xiàn)代架構(gòu)量身定做。功能實用不僅解決了認證授權(quán)的基本問題還提供了很多“錦上添花”的運維功能如踢人、查在線用戶等。潛在考量生態(tài)與社區(qū)作為一個較新的國產(chǎn)框架其社區(qū)規(guī)模、第三方集成豐富度、企業(yè)應(yīng)用案例的深度和廣度與Spring Security這樣的“老牌霸主”相比還有差距。深度定制能力雖然提供了很多配置項但其內(nèi)部設(shè)計的抽象層次和可插拔性對于需要極度定制化安全流程的超大型復(fù)雜系統(tǒng)可能需要評估其擴展能力是否足夠。“約定大于配置”的雙刃劍簡單的代價可能是對底層細節(jié)的屏蔽。如果你需要深入理解或調(diào)整其底層安全機制如自定義Token生成算法、復(fù)雜的權(quán)限合并邏輯可能需要閱讀源碼。sa-token非常適合快速啟動的中小型項目、初創(chuàng)公司產(chǎn)品或者作為微服務(wù)架構(gòu)中統(tǒng)一認證授權(quán)的輕量級解決方案。它的出現(xiàn)給了我們一個在Spring Security和Shiro之外非常優(yōu)秀的備選。4. 框架選型核心考量因素看了上面三個框架的解析你可能已經(jīng)有些感覺了。但在實際項目中做技術(shù)選型不能只看特性列表更需要結(jié)合你的具體上下文。下面這張表從幾個關(guān)鍵維度進行了對比并附上我的選型建議特性維度Spring SecurityApache ShiroSa-Token學(xué)習(xí)曲線陡峭概念多配置復(fù)雜平緩API直觀易懂非常平緩注解驅(qū)動上手極快功能廣度極其全面企業(yè)級功能全覆蓋滿足大部分常見需求覆蓋核心需求并提供實用增值功能與Spring集成原生無縫集成深度整合通過starter集成良好通過starter集成良好注解風(fēng)格很“Spring”微服務(wù)支持需結(jié)合Spring Cloud OAuth2/Spring Cloud Gateway等組件較弱需自行解決分布式會話原生支持好無狀態(tài)Token、分布式會話設(shè)計理念全面、嚴謹、可定制像一套安全基礎(chǔ)設(shè)施簡單、直觀、輕量像一個安全工具庫簡單、強大、面向現(xiàn)代應(yīng)用像一套開箱即用的安全解決方案典型適用場景大型復(fù)雜企業(yè)應(yīng)用、需要深度定制安全策略、與Spring全家桶緊密集成的項目中小型單體應(yīng)用、非Spring項目、需要快速實現(xiàn)安全功能且對復(fù)雜度敏感的項目中小型項目、快速原型開發(fā)、前后端分離架構(gòu)、微服務(wù)架構(gòu)、追求開發(fā)效率的團隊選型建議如果你的項目基于Spring Boot/Cloud且團隊有學(xué)習(xí)能力或已有經(jīng)驗Spring Security是長期來看最穩(wěn)妥、擴展性最強的選擇。它能伴隨你的業(yè)務(wù)從簡單到復(fù)雜。如果你的項目不是Spring體系或者你只是想為一個簡單應(yīng)用快速添加登錄功能討厭復(fù)雜的配置Apache Shiro或Sa-Token都是很好的選擇。Shiro更經(jīng)典、穩(wěn)定Sa-Token更現(xiàn)代、開發(fā)體驗更爽。如果你的項目是全新的前后端分離微服務(wù)架構(gòu)追求高效的開發(fā)迭代速度強烈建議你嘗試Sa-Token。它在設(shè)計上就規(guī)避了傳統(tǒng)框架在現(xiàn)代架構(gòu)下的許多痛點。5. 常見問題與實戰(zhàn)避坑指南在實際集成和使用這些框架時總會遇到一些“坑”。這里我總結(jié)幾個最常見的問題和解決思路。5.1 密碼存儲與加密問題如何安全地存儲用戶密碼錯誤做法明文存儲、使用MD5或SHA-256簡單哈希容易被彩虹表破解。正確做法使用加鹽的、自適應(yīng)成本的哈希算法如BCrypt、SCrypt或Argon2。Spring Security 直接使用BCryptPasswordEncoder。Apache Shiro 使用HashedCredentialsMatcher并配置相應(yīng)的哈希算法和鹽。Sa-Token 框架不強制密碼加密方式你需要在登錄邏輯中自行調(diào)用BCrypt等工具進行校驗。核心原理BCrypt算法每次哈希都會生成一個隨機的鹽salt并與哈希結(jié)果一起存儲。驗證時用存儲的鹽和輸入的密碼重新計算哈希進行比對。這確保了即使兩個用戶密碼相同其存儲的哈希值也不同極大增強了安全性。自適應(yīng)成本參數(shù)如strength允許你隨著硬件性能提升而增加計算開銷以對抗暴力破解。5.2 分布式環(huán)境下的會話管理問題在微服務(wù)或集群部署中用戶的Session或登錄狀態(tài)如何在不同服務(wù)/服務(wù)器間共享基于Session的方案Spring Security, Shiro默認 需要將Session存儲到外部集中式緩存如Redis中。Spring Security可集成Spring Session實現(xiàn)Shiro需配置SessionDAO為Redis實現(xiàn)?；跓o狀態(tài)Token的方案Sa-Token默認Spring Security也可用JWT 這是更流行的現(xiàn)代方案。用戶登錄后服務(wù)器生成一個簽名的Token如JWT返回給客戶端?？蛻舳撕罄m(xù)請求在Header中攜帶此Token。服務(wù)器只需驗證Token的簽名和有效性無需存儲會話狀態(tài)。但需注意Token的注銷和刷新問題。避坑技巧如果采用JWT請勿在Token中存放敏感信息如密碼因為JWT內(nèi)容是可解碼的盡管不可篡改。為JWT設(shè)置合理的過期時間并設(shè)計好Token刷新機制。如果需要實現(xiàn)“強制下線”功能無狀態(tài)Token會比較麻煩通常需要引入一個黑名單機制將需失效的Token ID存入Redis這會引入一定的狀態(tài)。Sa-Token的Token設(shè)計在這方面做了優(yōu)化其默認的Token格式更容易管理。5.3 權(quán)限注解不生效問題在Spring Security或Sa-Token中使用了PreAuthorize或SaCheckPermission注解但發(fā)現(xiàn)根本沒有攔截校驗。可能原因及排查Spring Security確保配置類上開啟了方法安全注解支持EnableGlobalMethodSecurity(prePostEnabled true)。確保該方法的調(diào)用路徑經(jīng)過了Spring的代理即是通過Spring容器注入的Bean調(diào)用的而不是類內(nèi)部直接調(diào)用this.method()。內(nèi)部調(diào)用會繞過代理導(dǎo)致注解失效。Sa-Token確保在啟動類或配置類上添加了EnableSaToken注解。檢查攔截器配置。Sa-Token的注解鑒權(quán)默認通過攔截器實現(xiàn)需確保相關(guān)路徑未被排除在攔截之外。5.4 跨域請求攜帶Cookie/Token失敗問題前后端分離項目前端發(fā)起請求時瀏覽器無法自動攜帶Cookie或自定義的Authorization Header。解決方案這主要是瀏覽器的同源策略和安全限制導(dǎo)致的。服務(wù)端必須正確配置CORS跨域資源共享。在Spring Security中需要在HttpSecurity配置中顯式啟用CORS并配置允許的源、頭、方法等。http.cors().configurationSource(corsConfigurationSource()) // 啟用CORS客戶端如果使用Cookie需要設(shè)置withCredentials: true在axios或fetch中。如果使用自定義Header如Authorization: Bearer xxx服務(wù)端CORS配置必須允許該HeaderexposedHeaders。更佳實踐對于無狀態(tài)Token通常不推薦使用Cookie易受CSRF攻擊而是將Token放在請求Header中。同時可以考慮將Token存儲在前端的localStorage或sessionStorage中并在每次請求時手動添加到Header。5.5 權(quán)限設(shè)計混亂RBAC模型落地問題理解了RBAC概念但在數(shù)據(jù)庫設(shè)計和業(yè)務(wù)代碼中不知如何落地。經(jīng)典的五表設(shè)計用戶表 (user) 存儲用戶基本信息。角色表 (role) 存儲角色信息。權(quán)限表 (permission) 存儲具體的權(quán)限點通常對應(yīng)API或前端資源格式可以是資源:操作如user:add,article:delete。用戶-角色關(guān)聯(lián)表 (user_role) 多對多關(guān)系記錄用戶擁有哪些角色。角色-權(quán)限關(guān)聯(lián)表 (role_permission) 多對多關(guān)系記錄角色擁有哪些權(quán)限。查詢用戶權(quán)限的流程用戶登錄時根據(jù)其user_id查詢user_role表得到role_id列表。根據(jù)role_id列表查詢role_permission表得到所有permission_id列表需去重。根據(jù)permission_id列表查詢permission表得到具體的權(quán)限字符串列表。將這個權(quán)限列表設(shè)置到當(dāng)前用戶的上下文中如Spring Security的Authentication對象或Shiro的AuthorizationInfo。進階思考對于更復(fù)雜的場景可以引入“用戶組”概念或者使用“數(shù)據(jù)權(quán)限”來補充RBAC控制用戶能看到哪些數(shù)據(jù)行例如只能看到自己部門的數(shù)據(jù)。這通常需要在業(yè)務(wù)邏輯層進行額外的過濾處理?？蚣転槲覀兘鉀Q了認證和鑒權(quán)的技術(shù)實現(xiàn)但清晰、可維護的權(quán)限模型設(shè)計始終是開發(fā)者的責(zé)任。在項目初期花時間設(shè)計好角色和權(quán)限的劃分能為后續(xù)的迭代省去無數(shù)麻煩。