一、為什麼要使用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": "John Doe",
 "admin": true
}
// 3. Signature簽名
// 根據alg演算法與私有祕鑰進行加密得到的簽名字串
// 這一段是最重要的敏感資訊，只能在服務端解密
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), SECREATE_KEY)

1、Header 頭部：頭部包含了兩部分，token 型別和採用的加密演算法。它會使用 Base64 編碼組成 JWT 結構的第一部分,如果你使用Node.js，可以用Node.js的包base64url來得到這個字串。

2、Payload 負載：這部分就是我們存放資訊的地方了，你可以把使用者 ID 等資訊放在這裡，JWT 規範裡面對這部分有進行了比較詳細的介紹，常用的由 iss（簽發者），exp（過期時間），sub（面向的使用者），aud（接收方），iat（簽發時間）。同樣的，它會使用 Base64 編碼組成 JWT 結構的第二部分

　　三個部分通過.連線在一起就是我們的 JWT 了，它可能長上面字串那個樣子，長度和你的加密演算法和私鑰有關係。

　　最後一步簽名的過程，實際上是對頭部以及負載內容進行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之後進行修改，再進行編碼，最後加上之前的簽名組合形成新的JWT的話，那麼伺服器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道伺服器加密時用的金鑰的話，得出來的簽名也是不一樣的。

　　在這裡大家一定會問一個問題：Base64是一種編碼，是可逆的，那麼我的資訊不就被暴露了嗎？是的。

　　所以，在JWT中，不應該在負載裡面加入任何敏感的資料。在上面的例子中，我們傳輸的是使用者的User ID。這個值實際上不是什麼敏感內容，一般情況下被知道也是安全的。但是像密碼這樣的內容就不能被放在JWT中了。如果將使用者的密碼放在了JWT中，那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

　　因此JWT適合用於向Web應用傳遞一些非敏感資訊。JWT還經常用於設計使用者認證和授權系統，甚至實現Web應用的單點登入。

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驗證成功，得到資訊

三、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中包含的使用者資訊進行其他邏輯操作，返回相應結果。

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的方式則沒有這個問題的存在，因為使用者的狀態已經被傳送到了客戶端。