您好,登錄后才能下訂單哦!
這篇文章主要介紹如何實現SpringSecurity+JWT認證流程,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
紙上得來終覺淺,覺知此事要躬行。
本文適合:對Spring Security有一點了解或者跑過簡單demo但是對整體運行流程不明白的同學,對SpringSecurity有興趣的也可以當作你們的入門教程,示例代碼中也有很多注釋。
本文代碼:碼云地址 GitHub地址
大家在做系統的時候,一般做的第一個模塊就是認證與授權模塊,因為這是一個系統的入口,也是一個系統最重要最基礎的一環,在認證與授權服務設計搭建好了之后,剩下的模塊才得以安全訪問。
市面上一般做認證授權的框架就是shiro
和Spring Security
,也有大部分公司選擇自己研制。出于之前看過很多Spring Security
的入門教程,但都覺得講的不是太好,所以我這兩天在自己鼓搗Spring Security
的時候萌生了分享一下的想法,希望可以幫助到有興趣的人。
Spring Security
框架我們主要用它就是解決一個認證授權功能,所以我的文章主要會分為兩部分:
我會為大家用一個Spring Security + JWT + 緩存的一個demo來展現我要講的東西,畢竟腦子的東西要體現在具體事物上才可以更直觀的讓大家去了解去認識。
學習一件新事物的時候,我推薦使用自頂向下的學習方法,這樣可以更好的認識新事物,而不是盲人摸象。
注:只涉及到用戶認證授權不涉及oauth3之類的第三方授權。
想上手 Spring Security 一定要先了解它的工作流程,因為它不像工具包一樣,拿來即用,必須要對它有一定的了解,再根據它的用法進行自定義操作。
我們可以先來看看它的工作流程:
在Spring Security的
官方文檔上有這么一句話:
Spring Security's web infrastructure is based entirely on standard servlet filters.
Spring Security 的web基礎是Filters。
這句話展示了Spring Security
的設計思想:即通過一層層的Filters來對web請求做處理。
放到真實的Spring Security
中,用文字表述的話可以這樣說:
一個web請求會經過一條過濾器鏈,在經過過濾器鏈的過程中會完成認證與授權,如果中間發現這條請求未認證或者未授權,會根據被保護API的權限去拋出異常,然后由異常處理器去處理這些異常。
用圖片表述的話可以這樣畫,這是我在百度找到的一張圖片:
如上圖,一個請求想要訪問到API就會以從左到右的形式經過藍線框框里面的過濾器,其中綠色部分是我們本篇主要講的負責認證的過濾器,藍色部分負責異常處理,橙色部分則是負責授權。
圖中的這兩個綠色過濾器我們今天不會去說,因為這是Spring Security對form表單認證和Basic認證內置的兩個Filter,而我們的demo是JWT認證方式所以用不上。
如果你用過Spring Security
就應該知道配置中有兩個叫formLogin
和httpBasic
的配置項,在配置中打開了它倆就對應著打開了上面的過濾器。
formLogin
對應著你form表單認證方式,即UsernamePasswordAuthenticationFilter。httpBasic
對應著Basic認證方式,即BasicAuthenticationFilter。換言之,你配置了這兩種認證方式,過濾器鏈中才會加入它們,否則它們是不會被加到過濾器鏈中去的。
因為Spring Security
自帶的過濾器中是沒有針對JWT這種認證方式的,所以我們的demo中會寫一個JWT的認證過濾器,然后放在綠色的位置進行認證工作。
知道了Spring Security的大致工作流程之后,我們還需要知道一些非常重要的概念也可以說是組件:
Authentication
對象會放在里面。Authentication
,返回一個認證完成后的Authentication
對象。上下文對象,認證后的數據就放在這里面,接口定義如下:
public interface SecurityContext extends Serializable { // 獲取Authentication對象 Authentication getAuthentication(); // 放入Authentication對象 void setAuthentication(Authentication authentication); }
這個接口里面只有兩個方法,其主要作用就是get or setAuthentication
。
public class SecurityContextHolder { public static void clearContext() { strategy.clearContext(); } public static SecurityContext getContext() { return strategy.getContext(); } public static void setContext(SecurityContext context) { strategy.setContext(context); } }
可以說是SecurityContext
的工具類,用于get or set or clearSecurityContext
,默認會把數據都存儲到當前線程中。
public interface Authentication extends Principal, Serializable { Collection<? extends GrantedAuthority> getAuthorities(); Object getCredentials(); Object getDetails(); Object getPrincipal(); boolean isAuthenticated(); void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException; }
這幾個方法效果如下:
getAuthorities
: 獲取用戶權限,一般情況下獲取到的是用戶的角色信息。getCredentials
: 獲取證明用戶認證的信息,通常情況下獲取到的是密碼等信息。getDetails
: 獲取用戶的額外信息,(這部分信息可以是我們的用戶表中的信息)。getPrincipal
: 獲取用戶身份信息,在未認證的情況下獲取到的是用戶名,在已認證的情況下獲取到的是 UserDetails。isAuthenticated
: 獲取當前Authentication
是否已認證。setAuthenticated
: 設置當前Authentication
是否已認證(true or false)。Authentication
只是定義了一種在SpringSecurity進行認證過的數據的數據形式應該是怎么樣的,要有權限,要有密碼,要有身份信息,要有額外信息。
public interface AuthenticationManager { // 認證方法 Authentication authenticate(Authentication authentication) throws AuthenticationException; }
AuthenticationManager
定義了一個認證方法,它將一個未認證的Authentication
傳入,返回一個已認證的Authentication
,默認使用的實現類為:ProviderManager。
接下來大家可以構思一下如何將這四個部分,串聯起來,構成Spring Security進行認證的流程:
1. :point_right:先是一個請求帶著身份信息進來
2. :point_right:經過AuthenticationManager
的認證,
3. :point_right:再通過SecurityContextHolder
獲取SecurityContext
,
4. :point_right:最后將認證后的信息放入到SecurityContext
。
真正開始講訴我們的認證代碼之前,我們首先需要導入必要的依賴,數據庫相關的依賴可以自行選擇什么JDBC框架,我這里用的是國人二次開發的myabtis-plus。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.0</version> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.3.0</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.47</version> </dependency>
接著,我們需要定義幾個必須的組件。
由于我用的Spring-Boot是2.X所以必須要我們自己定義一個加密器:
@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }
這個Bean是不必可少的,Spring Security
在認證操作時會使用我們定義的這個加密器,如果沒有則會出現異常。
@Bean public AuthenticationManager authenticationManager() throws Exception { return super.authenticationManager(); }
這里將Spring Security
自帶的authenticationManager
聲明成Bean,聲明它的作用是用它幫我們進行認證操作,調用這個Bean的authenticate
方法會由Spring Security
自動幫我們做認證。
public class CustomUserDetailsService implements UserDetailsService { @Autowired private UserService userService; @Autowired private RoleInfoService roleInfoService; @Override public UserDetails loadUserByUsername(String s) throws UsernameNotFoundException { log.debug("開始登陸驗證,用戶名為: {}",s); // 根據用戶名驗證用戶 QueryWrapper<UserInfo> queryWrapper = new QueryWrapper<>(); queryWrapper.lambda().eq(UserInfo::getLoginAccount,s); UserInfo userInfo = userService.getOne(queryWrapper); if (userInfo == null) { throw new UsernameNotFoundException("用戶名不存在,登陸失敗。"); } // 構建UserDetail對象 UserDetail userDetail = new UserDetail(); userDetail.setUserInfo(userInfo); List<RoleInfo> roleInfoList = roleInfoService.listRoleByUserId(userInfo.getUserId()); userDetail.setRoleInfoList(roleInfoList); return userDetail; } }
實現UserDetailsService
的抽象方法并返回一個UserDetails對象,認證過程中SpringSecurity會調用這個方法訪問數據庫進行對用戶的搜索,邏輯什么都可以自定義,無論是從數據庫中還是從緩存中,但是我們需要將我們查詢出來的用戶信息和權限信息組裝成一個UserDetails返回。
UserDetails也是一個定義了數據形式的接口,用于保存我們從數據庫中查出來的數據,其功能主要是驗證賬號狀態和獲取權限,具體實現可以查閱我倉庫的代碼。
由于我們是JWT的認證模式,所以我們也需要一個幫我們操作Token的工具類,一般來說它具有以下三個方法就夠了:
在下文我的代碼里面,JwtProvider充當了Token工具類的角色,具體實現可以查閱我倉庫的代碼。
有了前面的講解之后,大家應該都知道用SpringSecurity
做JWT認證需要我們自己寫一個過濾器來做JWT的校驗,然后將這個過濾器放到綠色部分。
在我們編寫這個過濾器之前,我們還需要進行一個認證操作,因為我們要先訪問認證接口拿到token,才能把token放到請求頭上,進行接下來請求。
如果你不太明白,不要緊,先接著往下看我會在這節結束再次梳理一下。
訪問一個系統,一般最先訪問的是認證方法,這里我寫了最簡略的認證需要的幾個步驟,因為實際系統中我們還要寫登錄記錄啊,前臺密碼解密啊這些操作。
@Override public ApiResult login(String loginAccount, String password) { // 1 創建UsernamePasswordAuthenticationToken UsernamePasswordAuthenticationToken usernameAuthentication = new UsernamePasswordAuthenticationToken(loginAccount, password); // 2 認證 Authentication authentication = this.authenticationManager.authenticate(usernameAuthentication); // 3 保存認證信息 SecurityContextHolder.getContext().setAuthentication(authentication); // 4 生成自定義token UserDetail userDetail = (UserDetail) authentication.getPrincipal(); AccessToken accessToken = jwtProvider.createToken((UserDetails) authentication.getPrincipal()); // 5 放入緩存 caffeineCache.put(CacheName.USER, userDetail.getUsername(), userDetail); return ApiResult.ok(accessToken); }
這里一共五個步驟,大概只有前四步是比較陌生的:
這樣的話就算完成了,感覺上很簡單,因為主要認證操作都會由authenticationManager.authenticate()
幫我們完成。
接下來我們可以看看源碼,從中窺得Spring Security是如何幫我們做這個認證的(省略了一部分):
// AbstractUserDetailsAuthenticationProvider public Authentication authenticate(Authentication authentication){ // 校驗未認證的Authentication對象里面有沒有用戶名 String username = (authentication.getPrincipal() == null) ? "NONE_PROVIDED" : authentication.getName(); boolean cacheWasUsed = true; // 從緩存中去查用戶名為XXX的對象 UserDetails user = this.userCache.getUserFromCache(username); // 如果沒有就進入到這個方法 if (user == null) { cacheWasUsed = false; try { // 調用我們重寫UserDetailsService的loadUserByUsername方法 // 拿到我們自己組裝好的UserDetails對象 user = retrieveUser(username, (UsernamePasswordAuthenticationToken) authentication); } catch (UsernameNotFoundException notFound) { logger.debug("User '" + username + "' not found"); if (hideUserNotFoundExceptions) { throw new BadCredentialsException(messages.getMessage( "AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials")); } else { throw notFound; } } Assert.notNull(user, "retrieveUser returned null - a violation of the interface contract"); } try { // 校驗賬號是否禁用 preAuthenticationChecks.check(user); // 校驗數據庫查出來的密碼,和我們傳入的密碼是否一致 additionalAuthenticationChecks(user, (UsernamePasswordAuthenticationToken) authentication); } }
看了源碼之后你會發現和我們平常寫的一樣,其主要邏輯也是查數據庫然后對比密碼。
登錄之后效果如下:
我們返回token之后,下次請求其他API的時候就要在請求頭中帶上這個token,都按照JWT的標準來做就可以。
有了token之后,我們要把過濾器放在過濾器鏈中,用于解析token,因為我們沒有session,所以我們每次去辨別這是哪個用戶的請求的時候,都是根據請求中的token來解析出來當前是哪個用戶。
所以我們需要一個過濾器去攔截所有請求,前文我們也說過,這個過濾器我們會放在綠色部分用來替代UsernamePasswordAuthenticationFilter
,所以我們新建一個JwtAuthenticationTokenFilter
,然后將它注冊為Bean,并在編寫配置文件的時候需要加上這個:
@Bean public JwtAuthenticationTokenFilter jwtAuthenticationTokenFilter() { return new JwtAuthenticationTokenFilter(); } @Override protected void configure(HttpSecurity http) throws Exception { http.addFilterBefore(jwtAuthenticationTokenFilter(), UsernamePasswordAuthenticationFilter.class); }
addFilterBefore
的語義是添加一個Filter到XXXFilter之前,放在這里就是把JwtAuthenticationTokenFilter
放在UsernamePasswordAuthenticationFilter
之前,因為filter的執行也是有順序的,我們必須要把我們的filter放在過濾器鏈中綠色的部分才會起到自動認證的效果。
接下來我們可以看看JwtAuthenticationTokenFilter
的具體實現了:
@Override protected void doFilterInternal(@NotNull HttpServletRequest request, @NotNull HttpServletResponse response, @NotNull FilterChain chain) throws ServletException, IOException { log.info("JWT過濾器通過校驗請求頭token進行自動登錄..."); // 拿到Authorization請求頭內的信息 String authToken = jwtProvider.getToken(request); // 判斷一下內容是否為空且是否為(Bearer )開頭 if (StrUtil.isNotEmpty(authToken) && authToken.startsWith(jwtProperties.getTokenPrefix())) { // 去掉token前綴(Bearer ),拿到真實token authToken = authToken.substring(jwtProperties.getTokenPrefix().length()); // 拿到token里面的登錄賬號 String loginAccount = jwtProvider.getSubjectFromToken(authToken); if (StrUtil.isNotEmpty(loginAccount) && SecurityContextHolder.getContext().getAuthentication() == null) { // 緩存里查詢用戶,不存在需要重新登陸。 UserDetail userDetails = caffeineCache.get(CacheName.USER, loginAccount, UserDetail.class); // 拿到用戶信息后驗證用戶信息與token if (userDetails != null && jwtProvider.validateToken(authToken, userDetails)) { // 組裝authentication對象,構造參數是Principal Credentials 與 Authorities // 后面的攔截器里面會用到 grantedAuthorities 方法 UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, userDetails.getPassword(), userDetails.getAuthorities()); // 將authentication信息放入到上下文對象中 SecurityContextHolder.getContext().setAuthentication(authentication); log.info("JWT過濾器通過校驗請求頭token自動登錄成功, user : {}", userDetails.getUsername()); } } } chain.doFilter(request, response); }
代碼里步驟雖然說的很詳細了,但是可能因為代碼過長不利于閱讀,我還是簡單說說,也可以直接去倉庫查看源碼:
Authorization
請求頭對應的token信息UserDetail
信息即可UserDetail
用戶名與token中的是否一直。authentication
對象,把它放在上下文對象中,這樣后面的過濾器看到我們上下文對象中有authentication
對象,就相當于我們已經認證過了。這樣的話,每一個帶有正確token的請求進來之后,都會找到它的賬號信息,并放在上下文對象中,我們可以使用SecurityContextHolder
很方便的拿到上下文對象中的Authentication
對象。
完成之后,啟動我們的demo,可以看到過濾器鏈中有以下過濾器,其中我們自定義的是第5個:
:cat:‍ 就醬,我們登錄完了之后獲取到的賬號信息與角色信息我們都會放到緩存中,當帶著token的請求來到時,我們就把它從緩存中拿出來,再次放到上下文對象中去。
結合認證方法,我們的邏輯鏈就變成了:
登錄:point_right:拿到token:point_right:請求帶上token:point_right:JWT過濾器攔截:point_right:校驗token:point_right:將從緩存中查出來的對象放到上下文中
這樣之后,我們認證的邏輯就算完成了。
認證和JWT過濾器完成后,這個JWT的項目其實就可以跑起來了,可以實現我們想要的效果,如果想讓程序更健壯,我們還需要再加一些輔助功能,讓代碼更友好。
當用戶未登錄或者token解析失敗時會觸發這個處理器,返回一個非法訪問的結果。
當用戶本身權限不滿足所訪問API需要的權限時,觸發這個處理器,返回一個權限不足的結果。
用戶退出一般就是清除掉上下文對象和緩存就行了,你也可以做一下附加操作,這兩步是必須的。
JWT的項目token刷新也是必不可少的,這里刷新token的主要方法放在了token工具類里面,刷新完了把緩存重載一遍就行了,因為緩存是有有效期的,重新put可以重置失效時間。
這篇文我從上周日就開始構思了,為了能講的老嫗能解,修修改改了幾遍才發出來。
Spring Security
的上手的確有點難度,在我第一次去了解它的時候看的是尚硅谷的教程,那個視頻的講師拿它和Thymeleaf結合,這就導致網上也有很多博客去講Spring Security
的時候也是這種方式,而沒有去關注前后端分離。
也有教程做過濾器的時候是直接繼承UsernamePasswordAuthenticationFilter
,這樣的方法也是可行的,不過我們了解了整體的運行流程之后你就知道沒必要這樣做,不需要去繼承XXX,只要寫個過濾器然后放在那個位置就可以了。
以上是如何實現SpringSecurity+JWT認證流程的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。