一、為什么要使用Token？
在很多項目案例中，需要實現賬戶的功能，客戶端所有的功能都基於用戶已登陸的前提下才可以使用。這就要求每次客戶端像服務器請求數據時都要驗證賬戶是否正確，如果正確則按正常方式返回數據，如果錯誤則進行攔截並返回錯誤信息。
但是當客戶端頻繁向服務器請求數據的話，每次服務器都要頻繁地查詢數據庫。而Token正是為了減輕服務器的壓力，減少頻繁的查詢數據庫，使服務器更加健壯，並取代傳統使用session的方法來進行驗證。
前后端分離通過Restful API進行數據交互時，如何驗證用戶的登錄信息及權限。在原來的項目中，使用的是最傳統也是最簡單的方式，前端登錄，后端根據用戶信息生成一個token，並保存這個 token 和對應的用戶id到數據庫或Session中，接着把 token 傳給用戶，存入瀏覽器 cookie，之后瀏覽器請求帶上這個cookie，后端根據這個cookie值來查詢用戶，驗證是否過期。
但這樣做問題就很多，如果我們的頁面出現了 XSS 漏洞，由於 cookie 可以被 JavaScript 讀取，XSS 漏洞會導致用戶 token 泄露，而作為后端識別用戶的標識，cookie 的泄露意味着用戶信息不再安全。盡管我們通過轉義輸出內容，使用 CDN 等可以盡量避免 XSS 注入，但誰也不能保證在大型的項目中不會出現這個問題。
在設置 cookie 的時候，其實你還可以設置 httpOnly 以及 secure 項。設置 httpOnly 后 cookie 將不能被 JS 讀取，瀏覽器會自動的把它加在請求的 header 當中，設置 secure 的話，cookie 就只允許通過 HTTPS 傳輸。secure 選項可以過濾掉一些使用 HTTP 協議的 XSS 注入，但並不能完全阻止。
httpOnly 選項使得 JS 不能讀取到 cookie，那么 XSS 注入的問題也基本不用擔心了。但設置 httpOnly 就帶來了另一個問題，就是很容易的被 XSRF，即跨站請求偽造。當你瀏覽器開着這個頁面的時候，另一個頁面可以很容易的跨站請求這個頁面的內容。因為 cookie 默認被發了出去。
另外，如果將驗證信息保存在數據庫中，后端每次都需要根據token查出用戶id，這就增加了數據庫的查詢和存儲開銷。
若把驗證信息保存在session中，有加大了服務器端的存儲壓力。
那我們可不可以不要服務器去查詢呢？如果我們生成token遵循一定的規律，比如我們使用對稱加密算法來加密用戶id形成token，那么服務端以后其實只要解密該token就可以知道用戶的id是什么了。不過呢，我只是舉個例子而已，要是真這么做，只要你的對稱加密算法泄露了，其他人可以通過這種加密方式進行偽造token，那么所有用戶信息都不再安全了。恩，那用非對稱加密算法來做呢，其實現在有個規范就是這樣做的，就是我們接下來要介紹的 JWT。
二、token基礎
JWT 是一個開放標准(RFC 7519)，它定義了一種用於簡潔，自包含的用於通信雙方之間以 JSON 對象的形式安全傳遞信息的方法。JWT 可以使用 HMAC 算法或者是 RSA 的公鑰密鑰對進行簽名。它具備兩個特點：
-
簡潔(Compact)：可以通過URL, POST 參數或者在 HTTP header 發送，因為數據量小，傳輸速度快
-
自包含(Self-contained)：負載中包含了所有用戶所需要的信息，避免了多次查詢數據庫
一個JWT(Java Web Token)實際上就是一個字符串，它由 頭部、載荷與簽名 三部分組成。編碼之后的JWT是這樣的一串字符
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
由.分為三段，通過解碼可以得到。
// 1. Headers頭部 // 包括類別（typ）、加密算法（alg）
{ "alg": "HS256", "typ": "JWT" } // 2. Claims載荷 // 包括需要傳遞的用戶信息
{ "sub": "1234567890", "name": "gwf", "admin": true } // 3. Signature簽名 // 根據alg算法與私有秘鑰進行加密得到的簽名字串 // 這一段是最重要的敏感信息，只能在服務端解密
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), SECREATE_KEY)
1、Header 頭部：頭部用於描述關於該JWT的最基本的信息
頭部包含了兩部分，token 類型和采用的加密算法。它會使用 Base64 編碼組成 JWT 結構的第一部分，如果你使用Node.js，可以用Node.js的包base64url來得到這個字符串。
將上面的JSON對象進行[base64編碼]可以得到下面的字符串。這個字符串我們將它稱作JWT的Header
{ "typ": "JWT", "alg": "HS256" } eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
2、Payload 負載：Payload也是一個JSON對象，包含了一些其他的信息
這部分就是我們存放信息的地方了，你可以把用戶 ID 等信息放在這里，JWT 規范里面對這部分有進行了比較詳細的介紹，常用的由 iss（簽發者），exp（過期時間），sub（面向的用戶），aud（接收方），iat（簽發時間）。同樣的，它會使用 Base64 編碼組成 JWT 結構的第二部分
將上面的JSON對象進行[base64編碼]可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload
{ "sub": "1234567890", "name": "gwf", "admin": true } eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
注意：Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。
3、Signature 簽名：
.連接在一起（頭部在前），最后，我們將拼接完的字符串用HS256算法進行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用mystar作為密鑰的話，那么就可以得到我們加密后的內容：rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM，這部分就叫簽名。
三個部分通過 .連接在一起就是我們的 JWT 了，它可能長上面字符串那個樣子，長度和你的加密算法和私鑰有關系。
最后一步簽名的過程，實際上是對頭部以及負載內容進行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之后進行修改，再進行編碼，最后加上之前的簽名組合形成新的JWT的話，那么服務器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道服務器加密時用的密鑰的話，得出來的簽名也是不一樣的。
服務器應用在接受到JWT后，會首先對頭部和載荷的內容用同一算法再次簽名。如果服務器應用對頭部和載荷再次以同樣方法簽名之后發現，自己計算出來的簽名和接受到的簽名不一樣，那么就說明這個Token的內容被別人動過的，我們應該拒絕這個Token。
在這里大家一定會問一個問題：Base64是一種編碼，是可逆的，那么我的信息不就被暴露了嗎？是的。
所以，在JWT中，不應該在負載里面加入任何敏感的數據。在上面的例子中，我們傳輸的是用戶的User ID。這個值實際上不是什么敏感內容，一般情況下被知道也是安全的。但是像密碼這樣的內容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
因此JWT適合用於向Web應用傳遞一些非敏感信息。JWT還經常用於設計用戶認證和授權系統，甚至實現Web應用的單點登錄。
6、代碼實現const jwt = require('jsonwebtoken'); const secret = 'qwert'; //自定義
app.set('superSecret', secret); //生成token
const token = jwt.sign(user, app.get('superSecret')); //解碼token
jwt.verify(token, app.get('superSecret'), function (err, decoded){ //decoded 是得到的用戶信息
}
- 安裝
nodejs的模塊jsonwebtoken，設置一個字符串當作密鑰 - 如果登錄成功，服務器就根據用戶名和密鑰生成一個
token，並返回token給客戶端 - 如果想得到個人信息，就可以發送這個
token，經過verify驗證成功，得到信息
token存放在cookie中，相當於把session Id存放在cookie中
客戶端收到服務器返回的 JWT，可以儲存在 Cookie 里面，也可以儲存在 localStorage。此后，客戶端每次與服務器通信，都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。
Authorization: Bearer <token>
另一種做法是，跨域的時候，JWT 就放在 POST 請求的數據體里面。
三、JWT使用過程
- 首先，前端通過Web表單將自己的用戶名和密碼發送到后端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。
- 后端核對用戶名和密碼成功后，將用戶的id等其他信息作為JWT Payload（負載），將其與頭部分別進行Base64編碼拼接后簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字符串。
- 后端將JWT字符串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。
- 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
- 后端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
- 驗證通過后后端使用JWT中包含的用戶信息進行其他邏輯操作，返回相應結果。
四、token 對比 session 好處
1、和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在於Session是存儲在服務器端的，所以需要占用大量服務器內存，對於較大型應用而言可能還要保存許多的狀態。一般而言，大型應用還需要借助一些KV數據庫和一系列緩存機制來實現Session的存儲。
而JWT方式將用戶狀態分散到了客戶端中，可以明顯減輕服務端的內存壓力。除了用戶id之外，還可以存儲其他的和用戶相關的信息，例如該用戶是否是管理員、用戶所在的分組等。雖說JWT方式讓服務器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤存儲而言可能就不算什么了。具體是否采用，需要在不同場景下用數據說話。
2、單點登錄
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一台服務器上。對於有多個子域名的站點，每個子域名至少會對應一台不同的服務器，例如：www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要實現在login.taobao.com登錄后，在其他的子域名下依然可以取到Session，這要求我們在多台服務器上同步Session。使用JWT的方式則沒有這個問題的存在，因為用戶的狀態已經被傳送到了客戶端。