1. 摘要
本文講解JWT（JSON Web Token ）的定義，機制，格式和在跨域多網(wǎng)站單點登錄中的應(yīng)用。
2.內(nèi)容
2.1 什么是JWT ?
Json web token（JWT）是為了網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開發(fā)標(biāo)準(zhǔn)（RFC 7519），該token被設(shè)計為緊湊且安全的，特別適用于分布式站點的單點登陸（SSO）場景。JWT的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。
通俗來講，JWT是一個含簽名并攜帶用戶相關(guān)信息的加密串，頁面請求校驗登錄接口時，請求頭中攜帶JWT串到后端服務(wù)，后端通過簽名加密串匹配校驗，保證信息未被篡改。校驗通過則認(rèn)為是可靠的請求，將正常返回數(shù)據(jù)。
什么情況下使用JWT比較適合？
- 授權(quán)：
這是最常見的使用場景，解決單點登錄問題。因為JWT使用起來輕便，開銷小，服務(wù)端不用記錄用戶狀態(tài)信息（無狀態(tài)），所以使用比較廣泛； - 信息交換：
JWT是在各個服務(wù)之間安全傳輸信息的好方法。因為JWT可以簽名，例如，使用公鑰/私鑰對兒 - 可以確定請求方是合法的。此外，由于使用標(biāo)頭和有效負(fù)載計算簽名，還可以驗證內(nèi)容是否未被篡改。
2.2 JWT 的數(shù)據(jù)結(jié)構(gòu)
2.2.1 傳統(tǒng) session 認(rèn)證及其弊病
互聯(lián)網(wǎng)服務(wù)離不開用戶認(rèn)證。一般流程是下面這樣。
1、用戶向服務(wù)器發(fā)送用戶名和密碼。
2、服務(wù)器驗證通過后，在當(dāng)前對話（session）里面保存相關(guān)數(shù)據(jù)，比如用戶角色、登錄時間等等。
3、服務(wù)器向用戶返回一個 session_id，寫入用戶的 Cookie。
4、用戶隨后的每一次請求，都會通過 Cookie，將 session_id 傳回服務(wù)器。
5、服務(wù)器收到 session_id，找到前期保存的數(shù)據(jù)，由此得知用戶的身份。
這種模式的問題在于，擴展性（scaling）不好。單機當(dāng)然沒有問題，如果是服務(wù)器集群，或者是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求 session 數(shù)據(jù)共享，每臺服務(wù)器都能夠讀取 session。
舉例來說，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)?，F(xiàn)在要求，用戶只要在其中一個網(wǎng)站登錄，再訪問另一個網(wǎng)站就會自動登錄，請問怎么實現(xiàn)？
一種解決方案是 session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫或別的持久層。各種服務(wù)收到請求后，都向持久層請求數(shù)據(jù)。這種方案的優(yōu)點是架構(gòu)清晰，缺點是工程量比較大。另外，持久層萬一掛了，就會單點失敗。
另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端，每次請求都發(fā)回服務(wù)器。JWT 就是這種方案的一個代表。
2.2.2 JWT 的原理
JWT 的原理是，服務(wù)器認(rèn)證以后，生成一個 JSON 對象，發(fā)回給用戶，就像下面這樣.
{
"姓名": "張三",
"角色": "管理員",
"到期時間": "2018年7月1日0點0分"
}
以后，用戶與服務(wù)端通信的時候，都要發(fā)回這個 JSON 對象。服務(wù)器完全只靠這個對象認(rèn)定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個對象的時候，會加上簽名（詳見后文）。
服務(wù)器就不保存任何 session 數(shù)據(jù)了，也就是說，服務(wù)器變成無狀態(tài)了，從而比較容易實現(xiàn)擴展。
2.2.3 JWT 的數(shù)據(jù)結(jié)構(gòu)
實際的 JWT 大概就像下面這樣。
它是一個很長的字符串，中間用點（.）分隔成三個部分。注意，JWT 內(nèi)部是沒有換行的，這里只是為了便于展示，將它寫成了幾行。
JWT 的三個部分依次如下。
- Header（頭部）
- Payload（負(fù)載）
- Signature（簽名）
寫成一行，就是下面的樣子。
Header.Payload.Signature
下面依次介紹這三個部分。
2.2.3.1 Header
Header 部分是一個 JSON 對象，描述 JWT 的元數(shù)據(jù)，通常是下面的樣子。
{ "alg": "HS256", "typ": "JWT" }
上面代碼中，alg屬性表示簽名的算法（algorithm），默認(rèn)是 HMAC SHA256（寫成 HS256）；typ屬性表示這個令牌（token）的類型（type），JWT 令牌統(tǒng)一寫為JWT。
最后，將上面的 JSON 對象使用 Base64URL 算法（詳見后文）轉(zhuǎn)成字符串。
2.2.3.2 Payload
Payload 部分也是一個 JSON 對象，用來存放實際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個官方字段，供選用。
- iss (issuer)：簽發(fā)人
- exp (expiration time)：過期時間
- sub (subject)：主題
- aud (audience)：受眾
- nbf (Not Before)：生效時間
- iat (Issued At)：簽發(fā)時間
- jti (JWT ID)：編號
除了官方字段，你還可以在這個部分定義私有字段，下面就是一個例子。
{ "sub": "1234567890", "name": "John Doe", "admin": true }
注意，JWT 默認(rèn)是不加密的，任何人都可以讀到，所以不要把秘密信息放在這個部分。
這個 JSON 對象也要使用 Base64URL 算法轉(zhuǎn)成字符串。
2.2.3.3 Signature
Signature 部分是對前兩部分的簽名，防止數(shù)據(jù)篡改。
首先，需要指定一個密鑰（secret）。這個密鑰只有服務(wù)器才知道，不能泄露給用戶。然后，使用 Header 里面指定的簽名算法（默認(rèn)是 HMAC SHA256），按照下面的公式產(chǎn)生簽名。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，就可以返回給用戶。
2.2.3.4 Base64URL
前面提到，Header 和 Payload 串型化的算法是 Base64URL。這個算法跟 Base64 算法基本類似，但有一些小的不同。
JWT 作為一個令牌（token），有些場合可能會放到 URL（比如 api.example.com/?token=xxx）。Base64 有三個字符+、/和=，在 URL 里面有特殊含義，所以要被替換掉：=被省略、+替換成-，/替換成_ 。這就是 Base64URL 算法。
2.2.3.4
客戶端收到服務(wù)器返回的 JWT，可以儲存在 Cookie 里面，也可以儲存在 localStorage。
此后，客戶端每次與服務(wù)器通信，都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發(fā)送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。
Authorization: Bearer <token>
另一種做法是，跨域的時候，JWT 就放在 POST 請求的數(shù)據(jù)體里面。
2.3 JWT 認(rèn)證流程
常規(guī)的 JWT 認(rèn)證流程如下如：
相比于 session 認(rèn)證，JWT 省去了服務(wù)器存儲用戶信息的過程。
JWT 常見校驗流程:
其中設(shè)置 payload 校驗規(guī)則一般是檢查 nbf、exp 以及用戶自定義的一些字段。
2.4 使用JWT實現(xiàn)單點登錄（完全跨域方案）
基于 cookie 的單點登錄模式有一個弊病在于，其對應(yīng)的多個站點的頂級域名必須相同。
主要有以下三步：
項目一開始我先封裝了一個JWTHelper工具包（GitHub下載），主要提供了生成JWT、解析JWT以及校驗JWT的方法，其他還有一些加密相關(guān)操作。
接下來，我在客戶端項目中依賴JWTHelper工具包，并添加Interceptor攔截器，攔截需要校驗登錄的接口。攔截器中校驗JWT有效性，并在response中重新設(shè)置JWT的新值；
最后在JWT服務(wù)端，依賴JWT工具包，在登錄方法中，需要在登錄校驗成功后調(diào)用生成JWT方法，生成一個JWT令牌并且設(shè)置到response的header中。
參考 使用JWT實現(xiàn)單點登錄（完全跨域方案）https://blog.csdn.net/weixin_42873937/article/details/82460997
2.5 access_token和refresh_token
通常在使用JWT的時候會設(shè)置access_token和refresh_token兩個token，access_token有效期較短，refresh_token有效期較長，當(dāng)access_token過期之后，如果refresh_token沒有過期則可以換取新的access_token。我的疑問在于為什么不直接給access_token設(shè)置一個較長的有效期。如果是為了安全，能拿到access_token，拿到refresh_token就是輕而易舉的事；還有的說法是refresh_token中可以存放比access_token更多、驗證起來更復(fù)雜的信息。
Token作為用戶獲取受保護資源的憑證，必須設(shè)置一個過期時間，否則一次登錄便可永久使用，認(rèn)證功能就失去了意義。但是矛盾在于：過期時間設(shè)置得太長，用戶數(shù)據(jù)的安全性將大打折扣；過期時間設(shè)置得太短，用戶就必須每隔一段時間重新登錄，以獲取新的憑證，這會極大挫傷用戶的積極性。針對這一問題，我們可以利用Access / Refresh Token這一概念來平衡Token安全性和用戶體驗。
Access / Refresh Token是什么？
上圖表示Access/Refresh Token在客戶端、認(rèn)證服務(wù)器、資源服務(wù)器三者之間的傳遞關(guān)系，簡單來說：
- Access Token即“訪問令牌”，是客戶端向資源服務(wù)器換取資源的憑證；
- Refresh Token即“刷新令牌”，是客戶端向認(rèn)證服務(wù)器換取Access Token的憑證。
Access / Refresh Token如何使用？
上圖表示客戶端請求資源的過程中，Access Token 和 Refresh Token 是如何配合使用的：
1. 用戶提供身份信息（一般是[用戶名/密碼]，利用客戶端向認(rèn)證服務(wù)器換取 Refresh Token和Access Token）；
2. 客戶端攜帶Access Token訪問資源服務(wù)器，資源服務(wù)器識別Access Token并返回資源；
3. 當(dāng)Access Token過期或失效，客戶端再一次訪問資源服務(wù)器，資源服務(wù)器返回“無效token”報錯；
4. 客戶端通過Refresh Token向認(rèn)證服務(wù)器換取Access Token，認(rèn)證服務(wù)器返回新的Access Token。
3. 參考
（1）10分鐘了解JSON Web令牌（JWT）
https://baijiahao.baidu.com/s?id=1608021814182894637&wfr=spider&for=pc
（2）JWT的使用流程
https://blog.csdn.net/shmely/article/details/85915044
（3）JWT全面解讀、使用步驟
https://blog.csdn.net/achenyuan/article/details/80829401
（4）JSON Web Token 入門教程 -阮一峰
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
【說明】jwt結(jié)構(gòu)講得比較清晰。
（5）JWT(JSON Web Tokens)
https://www.cnblogs.com/zaixiuxing/p/6005968.html
（6）使用JWT實現(xiàn)單點登錄（完全跨域方案）
https://blog.csdn.net/weixin_42873937/article/details/82460997
（7）基于 JWT 的單點登錄設(shè)計
http://www.itdecent.cn/p/6c4e1804653f
【說明】有邏輯圖，介紹得清晰。
（8）JWT全面解讀、使用步驟
https://blog.csdn.net/achenyuan/article/details/80829401
【說明】JAVA實現(xiàn)代碼
（9）看圖理解JWT如何用于單點登錄
https://www.shuzhiduo.com/A/kPzORnodxn/
