參考：https://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
背景
一、跨域認證的問題（session面對分布式場景的不足）
1、使用者向伺服器發送使用者名和密碼。
2、伺服器驗證通過後，在目前對話（session）裡面儲存相關資料，比如使用者角色、登入時間等等。
3、伺服器向使用者傳回一個 session_id，寫入使用者的 Cookie。
4、使用者随後的每一次請求，都會通過 Cookie，将 session_id 傳回伺服器。
5、伺服器收到 session_id，找到前期儲存的資料，由此得知使用者的身份。
如果是伺服器叢集，或者是跨域的服務導向架構，就要求 session 資料共享，每台伺服器都能夠讀取 session。
舉例來說，A 網站和 B 網站是同一家公司的關聯服務。現在要求，使用者隻要在其中一個網站登入，再通路另一個網站就會自動登入，請問怎麼實作？
一種解決方案是 session 資料持久化，寫入資料庫或别的持久層。各種服務收到請求後，都向持久層請求資料。這種方案的優點是架構清晰，缺點是工程量比較大。另外，持久層萬一挂了，就會單點失敗。
另一種方案是伺服器索性不儲存 session 資料了，所有資料都儲存在用戶端，每次請求都發回伺服器。JWT 就是這種方案的一個代表。
JWT基礎
JWT 的原理是，伺服器認證以後，生成一個 JSON 對象，發回給使用者，就像下面這樣。
使用者與服務端通信的時候，都要發回這個 JSON 對象。伺服器完全隻靠這個對象認定使用者身份。為了防止使用者篡改資料，伺服器在生成這個對象的時候，會加上簽名（詳見後文）。
伺服器就不儲存任何 session 資料了，也就是說，伺服器變成無狀态了，進而比較容易實作擴充。
JWT組成：
1、Header
描述 JWT 的中繼資料，通常是下面的樣子。
{
"alg": "HS256",
"typ": "JWT"
} 上面代碼中，
alg
屬性表示簽名的算法（algorithm），預設是 HMAC SHA256（寫成 HS256）；
typ
屬性表示這個令牌（token）的類型（type），JWT 令牌統一寫為
JWT
。
最後，将上面的 JSON 對象使用 Base64URL 算法轉成字元串。
2、Payload
Payload 部分也是一個 JSON 對象，用來存放實際需要傳遞的資料。JWT 規定了7個官方字段，供選用。
- iss (issuer)：簽發人
- exp (expiration time)：過期時間
- sub (subject)：主題
- aud (audience)：閱聽人
- nbf (Not Before)：生效時間
- iat (Issued At)：簽發時間
- jti (JWT ID)：編号
已可以定義私有字段
注意，JWT 預設是不加密的，任何人都可以讀到，是以不要把秘密資訊放在這個部分。 這個 JSON 對象也要使用 Base64URL 算法轉成字元串。
3、Signature
對前兩部分的簽名，防止資料篡改。
首先，需要指定一個密鑰（secret）。這個密鑰隻有伺服器才知道，不能洩露給使用者。然後，使用 Header 裡面指定的簽名算法（預設是 HMAC SHA256），按照下面的公式産生簽名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出簽名以後，把 Header、Payload、Signature 三個部分拼成一個字元串，每個部分之間用"點"（ . ）分隔，就可以傳回給使用者。
Base64URL
前面提到，Header 和 Payload 串型化的算法是 Base64URL。這個算法跟 Base64 算法基本類似，但有一些小的不同。
JWT 作為一個令牌（token），有些場合可能會放到 URL（比如 api.example.com/?token=xxx）。Base64 有三個字元
+
、
/
和
=
，在 URL 裡面有特殊含義，是以要被替換掉：
=
被省略、
+
替換成
-
，
/
替換成
_
。這就是 Base64URL 算法。
JWT 的使用方式
用戶端收到伺服器傳回的 JWT，可以儲存在 Cookie 裡面，也可以儲存在 localStorage。
此後，用戶端每次與伺服器通信，都要帶上這個 JWT。你可以把它放在 Cookie 裡面自動發送，但是這樣不能跨域，是以更好的做法是放在 HTTP 請求的頭資訊
Authorization
字段裡面。
Authorization: Bearer <token>
另一種做法是，跨域的時候，JWT 就放在 POST 請求的資料體裡面。
JWT 的幾個特點
（1）JWT 預設是不加密，但也是可以加密的。生成原始 Token 以後，可以用密鑰再加密一次。
（2）JWT 不加密的情況下，不能将秘密資料寫入 JWT。
（3）JWT 不僅可以用于認證，也可以用于交換資訊。有效使用 JWT，可以降低伺服器查詢資料庫的次數。
（4）JWT 的最大缺點是，由于伺服器不儲存 session 狀态，是以無法在使用過程中廢止某個 token，或者更改 token 的權限。也就是說，一旦 JWT 簽發了，在到期之前就會始終有效，除非伺服器部署額外的邏輯。
（5）JWT 本身包含了認證資訊，一旦洩露，任何人都可以獲得該令牌的所有權限。為了減少盜用，JWT 的有效期應該設定得比較短。對于一些比較重要的權限，使用時應該再次對使用者進行認證。
（6）為了減少盜用，JWT 不應該使用 HTTP 協定明碼傳輸，要使用 HTTPS 協定傳輸
工具解密JWT字元串
https://jwt.io/#libraries-io
編碼
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.9.0</version>
</dependency> Key KEY = new SecretKeySpec("javastack".getBytes(),
SignatureAlgorithm.HS512.getJcaName());
Map<String, Object> stringObjectMap = new HashMap<String, Object>();
stringObjectMap.put("type", "1");
String payload = "{\"user_id\":\"1341137\", \"expire_time\":\"2018-01-01 0:00:00\"}";
String compactJws = Jwts.builder().setHeader(stringObjectMap)
.setPayload(payload).signWith(SignatureAlgorithm.HS512, KEY).compact();
System.out.println("jwt key:" + new String(KEY.getEncoded()));
System.out.println("jwt payload:" + payload);
System.out.println("jwt encoded:" + compactJws);
Jws<Claims> claimsJws = Jwts.parser().setSigningKey(KEY).parseClaimsJws(compactJws);
JwsHeader header = claimsJws.getHeader();
Claims body = claimsJws.getBody();
System.out.println("jwt header:" + header);
System.out.println("jwt body:" + body);
System.out.println("jwt body user-id:" + body.get("user_id", String.class)); 執行結果：