1印叁、跨域認(rèn)證的問題
互聯(lián)網(wǎng)服務(wù)離不開用戶認(rèn)證呆贿。一般流程就像下面這樣垃你。
1、用戶向服務(wù)器發(fā)送用戶名和密碼雾袱。
2官还、服務(wù)器驗證通過后，在當(dāng)前對話（session）里面保存相關(guān)數(shù)據(jù)林说，比如用戶角色屯伞、登錄時間等等。
3珠移、服務(wù)器向用戶返回一個 session_id末融，寫入用戶的 Cookie勾习。
4、用戶隨后的每一次請求乾颁，都會通過 Cookie艺栈，將 session_id 傳回服務(wù)器。
5巴席、服務(wù)器收到 session_id诅需，找到前期保存的數(shù)據(jù)堰塌，由此得知用戶的身份。
這種模式的問題在于场刑，擴(kuò)展性不好。單機(jī)當(dāng)然沒有問題邀桑，如果是服務(wù)器集群科乎，或者是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求 session 數(shù)據(jù)共享捏萍，每臺服務(wù)器都能夠讀取 session空闲。
舉例來說碴倾，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)。現(xiàn)在要求给赞，用戶只要在其中一個網(wǎng)站登錄矫户，再訪問另一個網(wǎng)站就會自動登錄残邀，請問怎么實現(xiàn)芥挣？
一種解決方案是 session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫或別的持久層空另。各種服務(wù)收到請求后蹋砚，都向持久層請求數(shù)據(jù)。這種方案的優(yōu)點是架構(gòu)清晰循榆，缺點是工程量比較大秧饮。另外，持久層萬一掛了柑船，就會單點失敗泼各。
另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端寸癌，每次請求都發(fā)回服務(wù)器弱贼。JWT 就是這種方案的一個代表吮旅。
2、JWT 的原理
JWT 的原理是檬嘀，服務(wù)器認(rèn)證以后责嚷，生成一個 JSON 對象罕拂，發(fā)回給用戶，就像下面這樣衷掷。
{
? ????"姓名": "張三",
? ????"角色": "管理員",
????? "到期時間": "2018年7月1日0點0分"
}
以后柿菩，用戶與服務(wù)端通信的時候，都要發(fā)回這個 JSON 對象懦胞。服務(wù)器完全只靠這個對象認(rèn)定用戶身份医瘫。為了防止用戶篡改數(shù)據(jù)旧困，服務(wù)器在生成這個對象的時候稼锅，會加上簽名（詳見后文）矩距。
服務(wù)器就不保存任何 session 數(shù)據(jù)了怖竭，也就是說痊臭，服務(wù)器變成無狀態(tài)了，從而比較容易實現(xiàn)擴(kuò)展允趟。
3、JWT 的數(shù)據(jù)結(jié)構(gòu)
它是一個很長的字符串鸦致，中間用點（.）分隔成三個部分潮剪。注意，JWT 內(nèi)部是沒有換行的分唾，這里只是為了便于展示抗碰，將它寫成了幾行。
JWT 的三個部分依次如下绽乔。
Header（頭部）
Payload（負(fù)載）
Signature（簽名）
寫成一行弧蝇，就是下面的樣子。
Header.Payload.Signature
下面依次介紹這三個部分迄汛。
3.1 Header
Header 部分是一個 JSON 對象捍壤，描述 JWT 的元數(shù)據(jù)，通常是下面的樣子。
{
? ? ? "alg": "HS256",
? ????"typ": "JWT"
}
上面代碼中专酗，alg屬性表示簽名的算法（algorithm）睹逃，默認(rèn)是 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 默認(rèn)是不加密的，任何人都可以讀到输虱，所以不要把秘密信息放在這個部分些楣。
這個 JSON 對象也要使用 Base64URL 算法轉(zhuǎn)成字符串。
3.3 Signature
Signature 部分是對前兩部分的簽名宪睹，防止數(shù)據(jù)篡改愁茁。
首先，需要指定一個密鑰（secret）亭病。這個密鑰只有服務(wù)器才知道鹅很，不能泄露給用戶。然后命贴，使用 Header 里面指定的簽名算法（默認(rèn)是 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 算法田轧。
4暴匠、JWT 的使用方式
客戶端收到服務(wù)器返回的 JWT，可以儲存在 Cookie 里面傻粘，也可以儲存在 localStorage每窖。
此后帮掉，客戶端每次與服務(wù)器通信，都要帶上這個 JWT岛请。你可以把它放在 Cookie 里面自動發(fā)送旭寿，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面崇败。
Authorization: Bearer <token>
另一種做法是盅称，跨域的時候，JWT 就放在 POST 請求的數(shù)據(jù)體里面后室。
5缩膝、JWT 的幾個特點
（1）JWT 默認(rèn)是不加密，但也是可以加密的岸霹。生成原始 Token 以后疾层，可以用密鑰再加密一次。
（2）JWT 不加密的情況下贡避，不能將秘密數(shù)據(jù)寫入 JWT痛黎。
（3）JWT 不僅可以用于認(rèn)證，也可以用于交換信息刮吧。有效使用 JWT湖饱，可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。
（4）JWT 的最大缺點是杀捻，由于服務(wù)器不保存 session 狀態(tài)井厌，因此無法在使用過程中廢止某個 token，或者更改 token 的權(quán)限致讥。也就是說仅仆，一旦 JWT 簽發(fā)了，在到期之前就會始終有效垢袱，除非服務(wù)器部署額外的邏輯墓拜。
（5）JWT 本身包含了認(rèn)證信息，一旦泄露请契，任何人都可以獲得該令牌的所有權(quán)限撮弧。為了減少盜用，JWT 的有效期應(yīng)該設(shè)置得比較短姚糊。對于一些比較重要的權(quán)限，使用時應(yīng)該再次對用戶進(jìn)行認(rèn)證授舟。
（6）為了減少盜用救恨，JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸释树。
轉(zhuǎn)自：http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
