JSON Web Token（縮寫 JWT）是目前最流行的跨域認(rèn)證解決方案，本文介紹它的原理和用法。

跨域認(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ù)。現(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 就是這種方案的一個代表。

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)擴展。

JWT 的數(shù)據(jù)結(jié)構(gòu)

實際的 JWT 大概就像下面這樣。

它是一個很長的字符串，中間用點（.）分隔成三個部分。注意，JWT 內(nèi)部是沒有換行的，這里只是為了便于展示，將它寫成了幾行。

JWT 的三個部分依次如下。

• Header（頭部）
• Payload（負(fù)載）
• Signature（簽名）

寫成一行，就是下面的樣子。

Header.Payload.Signature

下面依次介紹這三個部分。

Header

Header 部分是一個 JSON 對象，描述 JWT 的元數(shù)據(jù)，通常是下面的樣子。

{"alg": "HS256","typ": "JWT"}

上面代碼中，alg屬性表示簽名的算法（algorithm），默認(rèn)是 HMAC SHA256（寫成 HS256）；typ屬性表示這個令牌（token）的類型（type），JWT 令牌統(tǒng)一寫為JWT。

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請及時與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會在5工作日內(nèi)聯(lián)系您，一經(jīng)查實，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://www.cjxv.cn/21351.html