05.08 JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

目錄:

一、JWT介紹

二、基於spring cloud + zuul + jwt 實戰

三、源碼地址

一、JWT介紹:

JSON Web Token(JWT)是一個非常輕巧的規範。這個規範允許我們使用JWT在用戶和服務器之間傳遞安全可靠的信息。

讓我們來假想一下一個場景。在A用戶關注了B用戶的時候,系統發郵件給B用戶,並且附有一個鏈接“點此關注A用戶”。鏈接的地址可以是這樣的

https://your.awesome-app.com/make-friend/?from_user=B&target_user=A

上面的URL主要通過URL來描述這個當然這樣做有一個弊端,那就是要求用戶B用戶是一定要先登錄的。可不可以簡化這個流程,讓B用戶不用登錄就可以完成這個操作。JWT就允許我們做到這點。

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

JWT的組成

一個JWT實際上就是一個字符串,它由三部分組成,頭部、載荷與簽名。

JWT的適用場景

我們可以看到,JWT適合用於向Web應用傳遞一些非敏感信息。例如在上面提到的完成加好友的操作,還有諸如下訂單的操作等等。

其實JWT還經常用於設計用戶認證和授權系統,甚至實現Web應用的單點登錄。

優點

因為json的通用性,所以JWT是可以進行跨語言支持的,像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。因為有了payload部分,所以JWT可以在自身存儲一些其他業務邏輯所必要的非敏感信息。便於傳輸,jwt的構成非常簡單,字節佔用很小,所以它是非常便於傳輸的。它不需要在服務端保存會話信息, 所以它易於應用的擴展缺點

一旦拿到token, 可用它訪問服務器,直到過期,中間服務器無法控制它,如是它失效(有解決方案: 在 token 中保存信息,可添加額外的驗證,如加一個 flag, 把數據庫對應的flag失效,來控制token有效性)。

token的過期時間設置很關鍵,一般把它設到凌晨少人訪問時失效,以免用戶使用過程中失效而丟失數據。 - token保存的信息有限,且都是字符串。

安全相關不應該在jwt的payload部分存放敏感信息,因為該部分是客戶端可解密的部分。保護好secret私鑰,該私鑰非常重要。如果可以,請使用https協議有人提到jwt暴露簽名算法(alg),而且會有None(無簽名),所以建議隱去alg。

一般的協議制定都會考慮擴展性和普適性。但是我們在應用中可以採用我們默認的算法,而不是根據alg去處理。

二、基於spring cloud + zuul + jwt 實戰

1、介紹:

本案例採用雙token的方式完成jwt。其中accessToken 用於用戶身份認證。refreshToken用於當accessToken失效時重新生成。

案例做了特別處理,當用戶退出時,要主動將accessToken失效(redis維護),降低accessToken暴露的可能性。當accessToken做失效處理時,允許一定時間的容錯時間(配置文件可設置),目的是避免併發訪問時的異常。

2、實戰源碼

項目結構:

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

流程:

1、用戶登錄:

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

用戶登錄,zuul網關過濾器將訪問跳轉至認證微服務。在認證微服務驗證用戶名、密碼,驗證通過後生成accessToken 和refreshToken(注意:本案例使用用戶密碼當簽名密鑰,這樣就避免了密鑰集中洩密)。過期時間分別設置為1小時 和24小時(配置文件可修改這兩個時間)。

返回兩個token,在前端保存(本案例localStorage)如圖:

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

2、token認證訪問(accessToken有效):

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

當訪問需要token認證的url時,zuul網關過濾器將請求轉發至認證微服務,認證微服務通過accessToken驗證是否合法。如果合法,zuul網關繼續執行,訪問其他微服務。

3、token認證訪問(accessToken失效,refreshToken有效):

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

因為accessToken 的失效時間比refreshToken短,所以當accessToken失效時,refreshToken可能還未失效。因此前端主動發起二次請求,並將refreshToken發送到認證微服務,認證微服務驗證refreshToken有效後,再次生成新的accessToken和refreshToken,並返回給前端,保存。

4、accessToken和refreshToken 都失效

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)

當兩個token都失效時,前端引導用戶到登錄界面,重新登錄。

三、源碼

https://github.com/wzjgn/zktd-bigdata-platform

JWT +spring cloud +zuul 實戰案例分享(內附流程圖,源碼地址)


分享到:


相關文章: