Part 01

●JWT是什么？●

JWT（JSON Web Token）是一個(gè)開(kāi)放的行業(yè)標(biāo)準(zhǔn)（RFC 7519），自身包含了身份驗(yàn)證所需要的所有信息，因此我們的服務(wù)器不需要存儲(chǔ)用戶(hù)Session信息。這顯然增加了系統(tǒng)的可用性和伸縮性，大大減輕了服務(wù)端的壓力?？梢钥闯鯦WT更符合設(shè)計(jì)RESTful API時(shí)的Stateless（無(wú)狀態(tài)）原則。并且使用JWT認(rèn)證可以有效避免CSRF攻擊，因?yàn)镴WT一般是存在在localStorage中，使用JWT進(jìn)行身份驗(yàn)證的過(guò)程中是不會(huì)涉及到Cookie的。

Part 02

●JWT由哪些部分組成？●

JWT本質(zhì)上是一組字串，通常是這樣的：xxxxx.yyyyy.zzzzz，通過(guò)（.）切分成三個(gè)為Base64編碼的部分：

Header：描述JWT的元數(shù)據(jù)，定義了生成簽名的算法以及Token的類(lèi)型。

Payload：用來(lái)存放實(shí)際需要傳遞的數(shù)據(jù)。

Signature：服務(wù)器通過(guò)Payload、Header和一個(gè)密鑰(Secret)

使用Header里面指定的簽名算法（默認(rèn)是 HMAC SHA256）生成。

示例：

可以通過(guò)https://jwt.io對(duì)上述JWT進(jìn)行解碼，解碼之后便可得到Header、Payload、Signature這三部分。Header和Payload都是JSON格式的數(shù)據(jù)，Signature由Payload、Header和Secret(密鑰)通過(guò)特定的計(jì)算公式和加密算法得到。

Header

通常由兩部分組成。

typ（Type）：令牌類(lèi)型，也就是JWT

alg（Algorithm）：簽名算法，比如HS256

示例：

JSON形式的Header被轉(zhuǎn)換成Base64編碼，成為JWT的第一部。

Payload

包含了三種類(lèi)型的聲明。

Registered Claims（注冊(cè)聲明）：預(yù)定義的一些聲明，建議使用，但不強(qiáng)制。

Public Claims（公有聲明）：JWT簽發(fā)方可以自定義的聲明。

Private Claims（私有聲明）：JWT簽發(fā)方因?yàn)轫?xiàng)目需要而自定義的聲明。

下面是一些常見(jiàn)的注冊(cè)聲明：

iss（issuer）：JWT 簽發(fā)方。

iat（issued at time）：JWT簽發(fā)時(shí)間。

sub（subject）：JWT主題。

aud（audience）：JWT接收方。

exp（expiration time）：JWT的過(guò)期時(shí)間。

nbf（not before time）：JWT生效時(shí)間，早于該定義的時(shí)間的JWT不能被接受處理。

jti（JWT ID）：JWT唯一標(biāo)識(shí)。

示例：

Payload部分默認(rèn)是不加密的，一定不要將隱私信息存放在 Payload 當(dāng)中?。?！

JSON 形式的Payload被轉(zhuǎn)換成Base64編碼，成為JWT的第二部分。

Signature

對(duì)前兩部分的簽名，作用是防止JWT（主要是payload）被篡改。簽名的生成需要用到：Header+Payload、存放在服務(wù)端的密鑰(一定不要泄露出去)、簽名算法。簽名的計(jì)算公式如下：

算出簽名以后，把 Header、Payload、Signature三個(gè)部分拼成一個(gè)字符串，每個(gè)部分之間用"點(diǎn)"（.）分隔，這個(gè)字符串就是JWT。

Part 03

● JWT如何進(jìn)行用戶(hù)認(rèn)證？●

在基于JWT進(jìn)行身份驗(yàn)證的的應(yīng)用程序中，服務(wù)器通過(guò) Payload、Header和Secret(密鑰)創(chuàng)建JWT并將JWT發(fā)送給客戶(hù)端?？蛻?hù)端接收到JWT之后，會(huì)將其保存在Cookie或者localStorage里面，以后客戶(hù)端發(fā)出的所有請(qǐng)求都會(huì)攜帶這個(gè)令牌。

簡(jiǎn)化后的步驟如下：

1．用戶(hù)向服務(wù)器發(fā)送用戶(hù)名、密碼以及驗(yàn)證碼用于登陸系統(tǒng)。

2．如果用戶(hù)用戶(hù)名、密碼以及驗(yàn)證碼校驗(yàn)正確的話(huà)，服務(wù)端會(huì)返回已簽名的Token，也就是JWT。

3．用戶(hù)以后每次向后端發(fā)請(qǐng)求都在Header中帶上這個(gè)JWT。

4．服務(wù)端檢查JWT并從中獲取用戶(hù)相關(guān)信息。

兩點(diǎn)建議：

1．建議將JWT存放在localStorage中，放在Cookie中會(huì)有CSRF風(fēng)險(xiǎn)。

2．請(qǐng)求服務(wù)端并攜帶JWT的常見(jiàn)做法是將其放在HTTP Header的Authorization字段中（Authorization：Bearer Token）

Part 04

●JWT如何防止被篡改？●

服務(wù)器返回簽名之后，即使JWT被泄露或者截獲，黑客也沒(méi)辦法同時(shí)篡改Signature、Header、Payload。

這是為什么呢？因?yàn)榉?wù)端拿到JWT之后，會(huì)解析出其中包含的Header、Payload 以及Signature。服務(wù)端會(huì)根據(jù)Header、Payload、密鑰再次生成一個(gè)Signature。拿新生成的Signature和JWT中的Signature作對(duì)比，如果一樣就說(shuō)明Header和Payload沒(méi)有被修改。

不過(guò)，如果服務(wù)端的秘鑰也被泄露的話(huà)，黑客就可以同時(shí)篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后，再重新生成一個(gè)Signature就可以了。

?注意：密鑰一定保管好，一定不要泄露出去。JWT安全的核心在于簽名，簽名安全的核心在密鑰。

Part 05

● JWT如何加強(qiáng)安全性？●

1．使用安全系數(shù)高的加密算法。

2．使用成熟的開(kāi)源庫(kù)，沒(méi)必要造輪子。

3．JWT存放在localStorage中而不是Cookie中，避免CSRF風(fēng)險(xiǎn)。

4．一定不要將隱私信息存放在Payload當(dāng)中。

5．密鑰一定保管好，一定不要泄露出去。JWT安全的核心在于簽名，簽名安全的核心在密鑰。

6．Payload要加入exp（JWT的過(guò)期時(shí)間），永久有效的JWT不合理。并且JWT的過(guò)期時(shí)間不易過(guò)長(zhǎng)。

Part 06

● JWT有哪些優(yōu)缺點(diǎn)？●

- 優(yōu)點(diǎn)

1．無(wú)狀態(tài)：自身攜帶用戶(hù)信息，不需要在服務(wù)器上保存session信息。

2．可有效避免CSRF攻擊：CSRF攻擊需要依賴(lài)Cookie，然而JWT選擇存放在localStorage中，因此非法鏈接無(wú)法獲取JWT。

- 缺點(diǎn)

1．不可控：就比如說(shuō)，我們想要在JWT有效期內(nèi)廢棄一個(gè)JWT或者更改它的權(quán)限的話(huà)，并不會(huì)立即生效，通常需要等到有效期過(guò)后才可以。再比如說(shuō)，當(dāng)用戶(hù)Logout的話(huà)，JWT也還有效。

Part 07

● JWT使用總結(jié)●

在“約定優(yōu)于配置，配置優(yōu)于編碼”的開(kāi)發(fā)理念下，通過(guò)Apollo配置中心，程序員不需要每次更改線(xiàn)上配置都要重新發(fā)布服務(wù)，成功實(shí)現(xiàn)了將配置與編碼解耦，為線(xiàn)上服務(wù)變更配置提供了解決方案。

審核編輯：劉清