使用JWT進行身份認證

什么是JWT

Json web token(JWT), 是為了在網(wǎng)絡應用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標準(RFC 7519)师幕。該token被設計為緊湊且安全的蛉鹿，特別適用于分布式站點的單點登錄(SSO)場景煌集。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息述雾，以便于從資源服務器獲取資源，也可以增加一些額外的其它業(yè)務邏輯所必須的聲明信息，該token也可直接被用于認證豫柬，也可被加密锌钮。

http協(xié)議本身是一種無狀態(tài)的協(xié)議桥温，而這就意味著如果用戶向我們的應用提供了用戶名和密碼來進行用戶認證，那么下一次請求時梁丘，用戶還要再一次進行用戶認證才行侵浸，因為根據(jù)http協(xié)議，我們并不能知道是哪個用戶發(fā)出的請求氛谜，所以為了讓我們的應用能識別是哪個用戶發(fā)出的請求掏觉，我們只能在服務器存儲一份用戶登錄的信息，這份登錄信息會在響應時傳遞給瀏覽器值漫，告訴其保存為cookie,以便下次請求時發(fā)送給我們的應用澳腹，這樣我們的應用就能識別請求來自哪個用戶了,這就是傳統(tǒng)的基于session認證。\r\n \r\n但是這種基于session的認證使應用本身很難得到擴展杨何，隨著不同客戶端用戶的增加酱塔，獨立的服務器已無法承載更多的用戶，而這時候基于session認證應用的問題就會暴露出來危虱。

內(nèi)存: 每個用戶經(jīng)過我們的應用認證之后羊娃，我們的應用都要在服務端做一次記錄，以方便用戶下次請求的鑒別槽地，通常而言session都是保存在內(nèi)存中迁沫，而隨著認證用戶的增多，服務端的開銷會明顯增大捌蚊。
擴展性: 用戶認證之后集畅，服務端做認證記錄，如果認證的記錄被保存在內(nèi)存中的話缅糟，這意味著用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源挺智，這樣在分布式的應用上，相應的限制了負載均衡器的能力窗宦。這也意味著限制了應用的擴展能力赦颇。
CSRF: 因為是基于cookie來進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊赴涵。

基于token的鑒權機制類似于http協(xié)議也是無狀態(tài)的媒怯，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味著基于token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了髓窜，這就為應用的擴展提供了便利扇苞。

流程上是這樣的：

這個token必須要在每次請求時傳遞給服務端鳖敷，它應該保存在請求頭里脖苏，另外，服務端要支持CORS(跨來源資源共享)策略定踱，一般我們在服務端這么做就可以了.
Access-Control-Allow-Origin: *

第一部分稱為頭部（header),第二部分稱為載荷（payload)棍潘，第三部分是簽證（signature)。

jwt的頭部承載兩部分信息：

完整的頭部就像下面這樣的JSON：

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

然后將頭部進行base64加密（該加密是可以對稱解密的),構成了第一部分。

載荷就是存放有效信息的地方至扰。這個名字像是特指飛機上承載的貨品鳍徽，這些有效信息包含三個部分

標準中注冊的聲明(建議但不強制使用) ：

公共的聲明：公共的聲明可以添加任何的信息绷杜，一般添加用戶的相關信息或其他業(yè)務需要的必要信息.但不建議添加敏感信息直秆，因為該部分在客戶端可解密。

私有的聲明：私有聲明是提供者和消費者所共同定義的聲明鞭盟，一般不建議存放敏感信息圾结，因為base64是對稱解密的，意味著該部分信息可以歸類為明文信息齿诉。
定義一個payload:

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

然后將其進行base64加密筝野，得到JWT的第二部分。

jwt的第三部分是一個簽證信息粤剧，這個簽證信息由三部分組成：

header (base64后的)
payload (base64后的)
secret
這個部分需要base64加密后的header和base64加密后的payload使用.連接組成的字符串歇竟，然后通過header中聲明的加密方式進行加鹽secret組合加密，然后就構成了jwt的第三部分抵恋。

將這三部分用.連接成一個完整的字符串,構成了最終的jwt焕议。

注意：secret是保存在服務器端的，jwt的簽發(fā)生成也是在服務器端的弧关，secret就是用來進行jwt的簽發(fā)和jwt的驗證盅安，所以，它就是你服務端的私鑰世囊，在任何場景都不應該流露出去别瞭。一旦客戶端得知這個secret, 那就意味著客戶端是可以自我簽發(fā)jwt了。

一般是在請求頭里加入Authorization株憾，并加上Bearer標注：

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服務端會驗證token蝙寨，如果驗證通過就會返回相應的資源。整個流程就是這樣的:

jwt.png