JWT（JSON Web Token） 一、JWT的結構 JWT包含了使用 . 連線的三個部分組成，他們分別是Header標頭、payload負載、signature簽名： Header 在header中通常包含了兩部分：token型別和採用的加密演算法。 { "alg": "HS256", "typ": "JWT" } 接下來對這部分內容使用 Base64Url 編碼組成了JWT結構的第一部分。 Payload Token的第二部分是負載，它包含了claim， Claim是一些實體（通常指的使用者）的狀態和額外的元資料，有三種類型的claim： reserved, public 和 private.

• Reserved claims: 這些claim是JWT預先定義的，在JWT中並不會強制使用它們，而是推薦使用，常用的有 iss（簽發者）, exp（過期時間戳）, sub（面向的使用者）, aud（接收方）, iat（簽發時間）。
• Public claims：根據需要定義自己的欄位，注意應該避免衝突
• Private claims：這些是自定義的欄位，可以用來在雙方之間交換資訊

負載使用的例子： { "sub": "1234567890", "name": "John Doe", "admin": true } 上述的負載需要經過Base64Url編碼後作為JWT結構的第二部分。 Signature 建立簽名需要使用編碼後的header和payload以及一個金鑰（金鑰建議不要直接寫在程式碼裡，可以放到統一的配置中心，且不要輕易對外公開），使用header中指定簽名演算法進行簽名。例如如果希望使用HMAC SHA256演算法，那麼簽名應該使用下列方式建立： HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 簽名用於驗證訊息的傳送者以及訊息是沒有經過篡改的。 二、首先為什麼使用JWT？ 就不得不提傳統的Session認證的弊端，首先我們知道http協議本身是無狀態的，因此當用戶通過網頁將自己的使用者名稱和密碼傳遞給伺服器進行認證的時候，伺服器認證成功之後並不會儲存這次認證結果的，這就導致當我們下次再次請求時候必須還要進行登陸狀態的認證，但是這個時候伺服器並沒有儲存上次的認證結果，伺服器並不知道那個使用者是登陸成功的，所以因為這個情況，session認證機制就要求我們在首次登陸成功之後需要在伺服器記憶體中存放一份登陸資訊，同時響應給客戶端結果讓其本地生成cookie，這樣下次發起請求的時候，就可以攜帶這個cookie，去與伺服器中的session登陸資訊進行比對就知道發起這次請求的使用者是否是登陸狀態了，這就是session認證機制， 那麼session認證機制的問題有哪些呢： 1、這個機制隨著使用者體量的增加，伺服器中儲存的使用者登陸資訊會越來越多，會增加伺服器的壓力；2、在當今微服務大行其道的時候，多數伺服器都是採用的叢集的方式進行部署的，這就要求叢集中的session必須實現共享，這就對伺服器的負載均衡帶來了一定的麻煩； 3、對於前後端分離的專案，使用者請求從瀏覽器傳送通常也不是直接就到達伺服器的而是層層的中介軟體nginx進行轉發，session機制不太適用； 4、session機制對於跨域的情況很難去解決,cookie不支援跨域，就不是很友好了，對於單點登入不適用； 5、對於手機端，session機制也是不適用的，主要是手機端沒有cookie； 6、session認證本質基於cookie，所以如果cookie被截獲，使用者很容易收到跨站請求偽造攻擊。並且如果瀏覽器禁用了cookie，這種方式也會失效； 三、JWT認證的優勢 對比傳統的session認證方式，JWT的優勢是： 1、簡潔：JWT Token資料量小，傳輸速度也很快； 2、因為JWT Token是以JSON加密形式儲存在客戶端的，所以JWT是跨語言的，原則上任何web形式都支援； 3、不需要在服務端儲存會話資訊，也就是說不依賴於cookie和session，所以沒有了傳統session認證的弊端，特別適用於分散式微服務； 4、單點登入友好：使用Session進行身份認證的話，由於cookie無法跨域，難以實現單點登入。但是，使用token進行認證的話， token可以被儲存在客戶端的任意位置的記憶體中（一般情況是放在請求頭中），不一定是cookie，所以不依賴cookie，不會存在這些問題； 5、適合移動端應用：使用Session進行身份認證的話，需要儲存一份資訊在伺服器端，而且這種方式會依賴到Cookie（需要 Cookie 儲存 SessionId），所以不適合移動端； 6、無需考慮CSRF：由於不再依賴cookie，所以採用token認證方式不會發生CSRF，所以也就無需考慮CSRF的防禦； 7、自保含，jwt的負載中可以包含了所有使用者所需要的資訊，避免了多次查詢資料庫。 四、JWT流程 通俗地說，JWT的本質就是一個字串，它是將使用者資訊儲存到一個Json字串中，然後進行編碼後得到一個JWT token，並且這個JWT token帶有簽名信息，接收後可以校驗是否被篡改，所以可以用於在各方之間安全地將資訊作為Json物件傳輸。JWT的認證流程如下：   1、首先，前端通過Web表單將自己的使用者名稱和密碼傳送到後端的介面，這個過程一般是一個POST請求。建議的方式是通過SSL加密的傳輸(HTTPS)，從而避免敏感資訊被嗅探 2、後端核對使用者名稱和密碼成功後，將包含使用者資訊的資料作為JWT的Payload，將其與JWT Header分別進行Base64編碼拼接後簽名，形成一個JWT Token，形成的JWT Token就是一個如同lll.zzz.xxx的字串 3、後端將JWT Token字串作為登入成功的結果返回給前端。前端可以將返回的結果儲存在瀏覽器中，退出登入時刪除儲存的JWT Token即可 4、前端在每次請求時將JWT Token放入HTTP請求頭中的Authorization屬性中(解決XSS和XSRF問題) 5、後端檢查前端傳過來的JWT Token，驗證其有效性，比如檢查簽名是否正確、是否過期、token的接收方是否是自己等等 6、驗證通過後，後端解析出JWT Token中包含的使用者資訊，進行其他邏輯操作(一般是根據使用者資訊得到許可權等)，返回結果。   五、JWT應用場景 1、身份認證在這種場景下，一旦使用者完成了登陸，在接下來的每個請求中包含JWT，可以用來驗證使用者身份以及對路由，服務和資源的訪問許可權進行驗證。由於它的開銷非常小，可以輕鬆的在不同域名的系統中傳遞，所有目前在單點登入（SSO）中比較廣泛的使用了該技術。 2、資訊交換在通訊的雙方之間使用JWT對資料進行編碼是一種非常安全的方式，由於它的資訊是經過簽名的，可以確保傳送者傳送的資訊是沒有經過偽造的。

 

------這裡只記錄概念，具體的程式碼可參考API文件