目錄：
一、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的組成
一個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、實戰原始碼
專案結構：
流程：
1、使用者登入：
使用者登入，zuul閘道器過濾器將訪問跳轉至認證微服務。在認證微服務驗證使用者名稱、密碼，驗證通過後生成accessToken 和refreshToken（注意：本案例使用使用者密碼當簽名金鑰，這樣就避免了金鑰集中洩密）。過期時間分別設定為1小時 和24小時（配置檔案可修改這兩個時間）。
返回兩個token，在前端儲存（本案例localStorage）如圖：
2、token認證訪問（accessToken有效）：
當訪問需要token認證的url時，zuul閘道器過濾器將請求轉發至認證微服務，認證微服務透過accessToken驗證是否合法。如果合法，zuul閘道器繼續執行，訪問其他微服務。
3、token認證訪問（accessToken失效，refreshToken有效）：
因為accessToken 的失效時間比refreshToken短，所以當accessToken失效時，refreshToken可能還未失效。因此前端主動發起二次請求，並將refreshToken傳送到認證微服務，認證微服務驗證refreshToken有效後，再次生成新的accessToken和refreshToken，並返回給前端，儲存。
4、accessToken和refreshToken 都失效
當兩個token都失效時，前端引導使用者到登入介面，重新登入。
三、原始碼
https://github.com/wzjgn/zktd-bigdata-platform
