JSON Web Token（JWT）是目前最流行的跨域身份驗證解決方案叮叹。蟲蟲今天給大家介紹JWT的原理和用法。
1.跨域身份驗證
Internet服務無法與用戶身份驗證分開沛豌。一般過程如下。
1.用戶向服務器發(fā)送用戶名和密碼。
2.驗證服務器后端考，相關數(shù)據(jù)（如用戶角色图仓，登錄時間等）將保存在當前會話中罐盔。
3.服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie救崔。
4.用戶的每個后續(xù)請求都將通過在Cookie中取出session_id傳給服務器惶看。
5.服務器收到session_id并對比之前保存的數(shù)據(jù)，確認用戶的身份帚豪。
這種模式最大的問題是碳竟，沒有分布式架構，無法支持橫向擴展狸臣。如果使用一個服務器莹桅，該模式完全沒有問題。但是烛亦，如果它是服務器群集或面向服務的跨域體系結構的話诈泼，則需要一個統(tǒng)一的session數(shù)據(jù)庫庫來保存會話數(shù)據(jù)實現(xiàn)共享，這樣負載均衡下的每個服務器才可以正確的驗證用戶身份煤禽。
例如蟲蟲舉一個實際中常見的單點登陸的需求：站點A和站點B提供同一公司的相關服務☆泶铮現(xiàn)在要求用戶只需要登錄其中一個網站，然后它就會自動登錄到另一個網站檬果。怎么做瓮孙？
一種解決方案是聽過持久化session數(shù)據(jù)唐断，寫入數(shù)據(jù)庫或文件持久層等。收到請求后杭抠，驗證服務從持久層請求數(shù)據(jù)脸甘。該解決方案的優(yōu)點在于架構清晰，而缺點是架構修改比較費勁偏灿，整個服務的驗證邏輯層都需要重寫丹诀，工作量相對較大。而且由于依賴于持久層的數(shù)據(jù)庫或者問題系統(tǒng)翁垂，會有單點風險铆遭，如果持久層失敗，整個認證體系都會掛掉沿猜。
本文蟲蟲給大家介紹另外一種靈活的解決方案枚荣，通過客戶端保存數(shù)據(jù)，而服務器根本不保存會話數(shù)據(jù)邢疙，每個請求都被發(fā)送回服務器棍弄。 JWT是這種解決方案的代表。
2. JWT的原則
JWT的原則是在服務器身份驗證之后疟游，將生成一個JSON對象并將其發(fā)送回用戶呼畸，如下所示。
{
"UserName": "Chongchong",
"Role": "Admin",
"Expire": "2018-08-08 20:15:56"
}
之后颁虐，當用戶與服務器通信時蛮原，客戶在請求中發(fā)回JSON對象。服務器僅依賴于這個JSON對象來標識用戶另绩。為了防止用戶篡改數(shù)據(jù)儒陨，服務器將在生成對象時添加簽名（有關詳細信息，請參閱下文）笋籽。
服務器不保存任何會話數(shù)據(jù)蹦漠，即服務器變?yōu)闊o狀態(tài)，使其更容易擴展车海。
3. JWT的數(shù)據(jù)結構
典型的笛园，一個JWT看起來如下圖。
改對象為一個很長的字符串侍芝，字符之間通過"."分隔符分為三個子串研铆。注意JWT對象為一個長字串，各字串之間也沒有換行符州叠，此處為了演示需要棵红，我們特意分行并用不同顏色表示了。每一個子串表示了一個功能塊咧栗，總共有以下三個部分：
JWT的三個部分如下逆甜。JWT頭虱肄、有效載荷和簽名，將它們寫成一行如下交煞。
我們將在下面介紹這三個部分盯蝴。
3.1 JWT頭
JWT頭部分是一個描述JWT元數(shù)據(jù)的JSON對象狰右，通常如下所示旗吁。
{
"alg": "HS256",
"typ": "JWT"
}
在上面的代碼中厂画，alg屬性表示簽名使用的算法缕粹，默認為HMAC SHA256（寫為HS256）稚茅；typ屬性表示令牌的類型，JWT令牌統(tǒng)一寫為JWT平斩。
最后亚享，使用Base64 URL算法將上述JSON對象轉換為字符串保存。
3.2 有效載荷
有效載荷部分绘面，是JWT的主體內容部分欺税，也是一個JSON對象，包含需要傳遞的數(shù)據(jù)揭璃。 JWT指定七個默認字段供選擇晚凿。
iss：發(fā)行人
exp：到期時間
sub：主題
aud：用戶
nbf：在此之前不可用
iat：發(fā)布時間
jti：JWT ID用于標識該JWT
除以上默認字段外，我們還可以自定義私有字段瘦馍，如下例：
{
"sub": "1234567890",
"name": "chongchong",
"admin": true
}
請注意歼秽，默認情況下JWT是未加密的，任何人都可以解讀其內容情组，因此不要構建隱私信息字段燥筷，存放保密信息，以防止信息泄露院崇。
JSON對象也使用Base64 URL算法轉換為字符串保存肆氓。
3.3簽名哈希
簽名哈希部分是對上面兩部分數(shù)據(jù)簽名，通過指定的算法生成哈希底瓣，以確保數(shù)據(jù)不會被篡改谢揪。
首先，需要指定一個密碼（secret）濒持。該密碼僅僅為保存在服務器中键耕，并且不能向用戶公開。然后柑营，使用標頭中指定的簽名算法（默認情況下為HMAC SHA256）根據(jù)以下公式生成簽名屈雄。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)
在計算出簽名哈希后，JWT頭官套，有效載荷和簽名哈希的三個部分組合成一個字符串酒奶，每個部分用"."分隔蚁孔，就構成整個JWT對象。
3.4 Base64URL算法
如前所述惋嚎，JWT頭和有效載荷序列化的算法都用到了Base64URL杠氢。該算法和常見Base64算法類似，稍有差別另伍。
作為令牌的JWT可以放在URL中（例如api.example/?token=xxx）鼻百。 Base64中用的三個字符是"+"，"/"和"="摆尝，由于在URL中有特殊含義温艇，因此Base64URL中對他們做了替換："="去掉，"+"用"-"替換堕汞，"/"用"_"替換勺爱，這就是Base64URL算法，很簡單把讯检。
4. JWT的用法
客戶端接收服務器返回的JWT琐鲁，將其存儲在Cookie或localStorage中。
此后人灼，客戶端將在與服務器交互中都會帶JWT围段。如果將它存儲在Cookie中，就可以自動發(fā)送投放，但是不會跨域蒜撮，因此一般是將它放入HTTP請求的Header Authorization字段中。
Authorization: Bearer
當跨域時跪呈，也可以將JWT被放置于POST請求的數(shù)據(jù)主體中段磨。
5. JWT問題和趨勢
1、JWT默認不加密耗绿，但可以加密苹支。生成原始令牌后，可以使用改令牌再次對其進行加密误阻。
2债蜜、當JWT未加密方法是，一些私密數(shù)據(jù)無法通過JWT傳輸究反。
3寻定、JWT不僅可用于認證，還可用于信息交換精耐。善用JWT有助于減少服務器請求數(shù)據(jù)庫的次數(shù)狼速。
4、JWT的最大缺點是服務器不保存會話狀態(tài)卦停，所以在使用期間不可能取消令牌或更改令牌的權限向胡。也就是說恼蓬，一旦JWT簽發(fā)，在有效期內將會一直有效僵芹。
5处硬、JWT本身包含認證信息，因此一旦信息泄露拇派，任何人都可以獲得令牌的所有權限荷辕。為了減少盜用，JWT的有效期不宜設置太長件豌。對于某些重要操作桐腌，用戶在使用時應該每次都進行進行身份驗證。
6苟径、為了減少盜用和竊取，JWT不建議使用HTTP協(xié)議來傳輸代碼躬审，而是使用加密的HTTPS協(xié)議進行傳輸棘街。
