轉(zhuǎn)自：https://segmentfault.com/a/1190000005047525?utm_source=tuicool&utm_medium=referral
本文翻譯自JWT官方網(wǎng)站對JWT是什么以及能做什么的簡介笙隙。
JWT是一種用于雙方之間傳遞安全信息的簡潔的哗咆、URL安全的表述性聲明規(guī)范养盗。JWT作為一個(gè)開放的標(biāo)準(zhǔn)（RFC 7519），定義了一種簡潔的非凌，自包含的方法用于通信雙方之間以Json對象的形式安全的傳遞信息屹逛。因?yàn)閿?shù)字簽名的存在，這些信息是可信的篡诽，JWT可以使用HMAC算法或者是RSA的公私秘鑰對進(jìn)行簽名崖飘。
簡潔(Compact): 可以通過URL榴捡，POST參數(shù)或者在HTTP header發(fā)送，因?yàn)閿?shù)據(jù)量小朱浴，傳輸速度也很快
自包含(Self-contained)：負(fù)載中包含了所有用戶所需要的信息吊圾，避免了多次查詢數(shù)據(jù)庫
JWT的主要應(yīng)用場景
身份認(rèn)證在這種場景下，一旦用戶完成了登陸翰蠢，在接下來的每個(gè)請求中包含JWT项乒，可以用來驗(yàn)證用戶身份以及對路由，服務(wù)和資源的訪問權(quán)限進(jìn)行驗(yàn)證梁沧。由于它的開銷非常小檀何，可以輕松的在不同域名的系統(tǒng)中傳遞，所有目前在單點(diǎn)登錄（SSO）中比較廣泛的使用了該技術(shù)。
信息交換在通信的雙方之間使用JWT對數(shù)據(jù)進(jìn)行編碼是一種非常安全的方式频鉴，由于它的信息是經(jīng)過簽名的栓辜，可以確保發(fā)送者發(fā)送的信息是沒有經(jīng)過偽造的。
JWT的結(jié)構(gòu)
JWT包含了使用.分隔的三部分：
- Header 頭部
- Payload 負(fù)載
- Signature 簽名
其結(jié)構(gòu)看起來是這樣的xxxxx.yyyyy.zzzzz
Header
在header中通常包含了兩部分：token類型和采用的加密算法垛孔。
{ "alg": "HS256", "typ": "JWT"}
接下來對這部分內(nèi)容使用 Base64Url 編碼組成了JWT結(jié)構(gòu)的第一部分藕甩。
Payload
Token的第二部分是負(fù)載，它包含了claim周荐， Claim是一些實(shí)體（通常指的用戶）的狀態(tài)和額外的元數(shù)據(jù)狭莱，有三種類型的claim：reserved, public 和 private.
Reserved claims: 這些claim是JWT預(yù)先定義的，在JWT中并不會(huì)強(qiáng)制使用它們概作，而是推薦使用腋妙，常用的有 iss（簽發(fā)者）,exp（過期時(shí)間戳）, sub（面向的用戶）, aud（接收方）, iat（簽發(fā)時(shí)間）。
Public claims：根據(jù)需要定義自己的字段讯榕，注意應(yīng)該避免沖突
Private claims：這些是自定義的字段辉阶，可以用來在雙方之間交換信息
負(fù)載使用的例子：
{ "sub": "1234567890", "name": "John Doe", "admin": true}
上述的負(fù)載需要經(jīng)過Base64Url編碼后作為JWT結(jié)構(gòu)的第二部分。
Signature
創(chuàng)建簽名需要使用編碼后的header和payload以及一個(gè)秘鑰瘩扼，使用header中指定簽名算法進(jìn)行簽名谆甜。例如如果希望使用HMAC SHA256算法，那么簽名應(yīng)該使用下列方式創(chuàng)建：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
簽名用于驗(yàn)證消息的發(fā)送者以及消息是沒有經(jīng)過篡改的集绰。
完整的JWT
完整的JWT格式的輸出是以.分隔的三段Base64編碼规辱，與SAML等基于XML的標(biāo)準(zhǔn)相比，JWT在HTTP和HTML環(huán)境中更容易傳遞栽燕。
下列的JWT展示了一個(gè)完整的JWT格式罕袋，它拼接了之前的Header， Payload以及秘鑰簽名：
如何使用JWT碍岔？
在身份鑒定的實(shí)現(xiàn)中浴讯，傳統(tǒng)方法是在服務(wù)端存儲(chǔ)一個(gè)session，給客戶端返回一個(gè)cookie蔼啦，而使用JWT之后榆纽，當(dāng)用戶使用它的認(rèn)證信息登陸系統(tǒng)之后，會(huì)返回給用戶一個(gè)JWT捏肢，用戶只需要本地保存該token（通常使用local storage奈籽，也可以使用cookie）即可。
當(dāng)用戶希望訪問一個(gè)受保護(hù)的路由或者資源的時(shí)候鸵赫，通常應(yīng)該在Authorization頭部使用Bearer模式添加JWT衣屏，其內(nèi)容看起來是下面這樣：
Authorization: Bearer <token>
因?yàn)橛脩舻臓顟B(tài)在服務(wù)端的內(nèi)存中是不存儲(chǔ)的，所以這是一種無狀態(tài)的認(rèn)證機(jī)制辩棒。服務(wù)端的保護(hù)路由將會(huì)檢查請求頭Authorization中的JWT信息狼忱，如果合法膨疏，則允許用戶的行為。由于JWT是自包含的钻弄，因此減少了需要查詢數(shù)據(jù)庫的需要成肘。
JWT的這些特性使得我們可以完全依賴其無狀態(tài)的特性提供數(shù)據(jù)API服務(wù)，甚至是創(chuàng)建一個(gè)下載流服務(wù)斧蜕。因?yàn)镴WT并不使用Cookie的双霍，所以你可以使用任何域名提供你的API服務(wù)而不需要擔(dān)心跨域資源共享問題（CORS）。
下面的序列圖展示了該過程：
為什么要使用JWT批销？
相比XML格式洒闸，JSON更加簡潔，編碼之后更小均芽，這使得JWT比SAML更加簡潔丘逸，更加適合在HTML和HTTP環(huán)境中傳遞。
在安全性方面掀宋，SWT只能夠使用HMAC算法和共享的對稱秘鑰進(jìn)行簽名深纲，而JWT和SAML token則可以使用X.509認(rèn)證的公私秘鑰對進(jìn)行簽名。與簡單的JSON相比劲妙，XML和XML數(shù)字簽名會(huì)引入復(fù)雜的安全漏洞湃鹊。
因?yàn)镴SON可以直接映射為對象，在大多數(shù)編程語言中都提供了JSON解析器镣奋，而XML則沒有這么自然的文檔-對象映射關(guān)系币呵，這就使得使用JWT比SAML更方便。
