文章轉(zhuǎn)自：http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
JSON Web Token（縮寫 JWT）是目前最流行的跨域認證解決方案伶椿，本文介紹它的原理和用法溢十。
一缚陷、跨域認證的問題
互聯(lián)網(wǎng)服務離不開用戶認證阁谆。一般流程是下面這樣。
1、用戶向服務器發(fā)送用戶名和密碼舌稀。
2啊犬、服務器驗證通過后，在當前對話（session）里面保存相關數(shù)據(jù)壁查，比如用戶角色觉至、登錄時間等等。
3睡腿、服務器向用戶返回一個 session_id语御，寫入用戶的 Cookie。
4席怪、用戶隨后的每一次請求应闯，都會通過 Cookie，將 session_id 傳回服務器挂捻。
5碉纺、服務器收到 session_id，找到前期保存的數(shù)據(jù)刻撒，由此得知用戶的身份骨田。
這種模式的問題在于，擴展性（scaling）不好疫赎。單機當然沒有問題盛撑，如果是服務器集群，或者是跨域的服務導向架構捧搞，就要求 session 數(shù)據(jù)共享，每臺服務器都能夠讀取 session狮荔。
舉例來說胎撇，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關聯(lián)服務。現(xiàn)在要求殖氏，用戶只要在其中一個網(wǎng)站登錄晚树，再訪問另一個網(wǎng)站就會自動登錄，請問怎么實現(xiàn)雅采？
一種解決方案是 session 數(shù)據(jù)持久化爵憎，寫入數(shù)據(jù)庫或別的持久層。各種服務收到請求后婚瓜，都向持久層請求數(shù)據(jù)宝鼓。這種方案的優(yōu)點是架構清晰，缺點是工程量比較大巴刻。另外愚铡，持久層萬一掛了，就會單點失敗。
另一種方案是服務器索性不保存 session 數(shù)據(jù)了沥寥，所有數(shù)據(jù)都保存在客戶端碍舍，每次請求都發(fā)回服務器。JWT 就是這種方案的一個代表邑雅。
二片橡、JWT 的原理
JWT 的原理是，服務器認證以后淮野，生成一個 JSON 對象锻全，發(fā)回給用戶，就像下面這樣录煤。
{ "姓名": "張三", "角色": "管理員", "到期時間": "2018年7月1日0點0分" }
以后鳄厌，用戶與服務端通信的時候，都要發(fā)回這個 JSON 對象妈踊。服務器完全只靠這個對象認定用戶身份了嚎。為了防止用戶篡改數(shù)據(jù)，服務器在生成這個對象的時候廊营，會加上簽名（詳見后文）歪泳。
服務器就不保存任何 session 數(shù)據(jù)了，也就是說露筒，服務器變成無狀態(tài)了呐伞，從而比較容易實現(xiàn)擴展。
三慎式、JWT 的數(shù)據(jù)結構
實際的 JWT 大概就像下面這樣伶氢。
它是一個很長的字符串，中間用點（.）分隔成三個部分瘪吏。注意癣防，JWT 內(nèi)部是沒有換行的，這里只是為了便于展示掌眠，將它寫成了幾行蕾盯。
JWT 的三個部分依次如下梗脾。
- Header（頭部）
- Payload（負載）
- Signature（簽名）
寫成一行武鲁，就是下面的樣子翎朱。
Header.Payload.Signature
下面依次介紹這三個部分纸镊。
3.1 Header
Header 部分是一個 JSON 對象蔓倍，描述 JWT 的元數(shù)據(jù)篇亭，通常是下面的樣子昧碉。
{ "alg": "HS256", "typ": "JWT" }
上面代碼中嗽元，alg屬性表示簽名的算法（algorithm）沧烈，默認是 HMAC SHA256（寫成 HS256）掠兄；typ屬性表示這個令牌（token）的類型（type），JWT 令牌統(tǒng)一寫為JWT。
最后蚂夕，將上面的 JSON 對象使用 Base64URL 算法（詳見后文）轉(zhuǎn)成字符串迅诬。
3.2 Payload
Payload 部分也是一個 JSON 對象，用來存放實際需要傳遞的數(shù)據(jù)婿牍。JWT 規(guī)定了7個官方字段侈贷，供選用。
- iss (issuer)：簽發(fā)人
- exp (expiration time)：過期時間
- sub (subject)：主題
- aud (audience)：受眾
- nbf (Not Before)：生效時間
- iat (Issued At)：簽發(fā)時間
- jti (JWT ID)：編號
除了官方字段等脂，你還可以在這個部分定義私有字段俏蛮，下面就是一個例子。
{ "sub": "1234567890", "name": "John Doe", "admin": true }
注意上遥，JWT 默認是不加密的搏屑，任何人都可以讀到，所以不要把秘密信息放在這個部分粉楚。
這個 JSON 對象也要使用 Base64URL 算法轉(zhuǎn)成字符串辣恋。
3.3 Signature
Signature 部分是對前兩部分的簽名，防止數(shù)據(jù)篡改模软。
首先伟骨，需要指定一個密鑰（secret）。這個密鑰只有服務器才知道燃异，不能泄露給用戶携狭。然后，使用 Header 里面指定的簽名算法（默認是 HMAC SHA256）回俐，按照下面的公式產(chǎn)生簽名逛腿。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出簽名以后，把 Header鲫剿、Payload鳄逾、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔灵莲，就可以返回給用戶。
3.4 Base64URL
前面提到殴俱，Header 和 Payload 串型化的算法是 Base64URL政冻。這個算法跟 Base64 算法基本類似，但有一些小的不同线欲。
JWT 作為一個令牌（token）明场，有些場合可能會放到 URL（比如 api.example.com/?token=xxx）。Base64 有三個字符+李丰、/和=苦锨，在 URL 里面有特殊含義，所以要被替換掉：=被省略、+替換成-舟舒，/替換成_ 拉庶。這就是 Base64URL 算法。
四秃励、JWT 的使用方式
客戶端收到服務器返回的 JWT氏仗，可以儲存在 Cookie 里面，也可以儲存在 localStorage夺鲜。
此后皆尔，客戶端每次與服務器通信，都要帶上這個 JWT币励。你可以把它放在 Cookie 里面自動發(fā)送慷蠕，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面食呻。
Authorization: Bearer <token>
另一種做法是流炕，跨域的時候，JWT 就放在 POST 請求的數(shù)據(jù)體里面搁进。
五浪感、JWT 的幾個特點
（1）JWT 默認是不加密，但也是可以加密的饼问。生成原始 Token 以后影兽，可以用密鑰再加密一次。
（2）JWT 不加密的情況下莱革，不能將秘密數(shù)據(jù)寫入 JWT峻堰。
（3）JWT 不僅可以用于認證，也可以用于交換信息盅视。有效使用 JWT捐名，可以降低服務器查詢數(shù)據(jù)庫的次數(shù)。
（4）JWT 的最大缺點是闹击，由于服務器不保存 session 狀態(tài)镶蹋，因此無法在使用過程中廢止某個 token，或者更改 token 的權限赏半。也就是說贺归，一旦 JWT 簽發(fā)了，在到期之前就會始終有效断箫，除非服務器部署額外的邏輯拂酣。
（5）JWT 本身包含了認證信息，一旦泄露仲义，任何人都可以獲得該令牌的所有權限婶熬。為了減少盜用剑勾，JWT 的有效期應該設置得比較短。對于一些比較重要的權限赵颅，使用時應該再次對用戶進行認證虽另。
（6）為了減少盜用，JWT 不應該使用 HTTP 協(xié)議明碼傳輸性含，要使用 HTTPS 協(xié)議傳輸洲赵。
六、參考鏈接
- Introduction to JSON Web Tokens商蕴， by Auth0
- Sessionless Authentication using JWTs (with Node + Express + Passport JS), by Bryan Manuele
- Learn how to use JSON Web Tokens, by dwyl
