2713
作者：楊強(qiáng)，單位：中國移動(dòng)智慧家庭運(yùn)營中心成都業(yè)務(wù)支持中心
我們在做應(yīng)用系統(tǒng)時(shí)避免不了用戶的認(rèn)證授權(quán)，說簡單點(diǎn)就是：認(rèn)證你是誰，授權(quán)你有什么權(quán)限。在這里先來談?wù)動(dòng)脩舻恼J(rèn)證，目前常用的認(rèn)證方式有兩種：基于session認(rèn)證、基于token認(rèn)證。而JWT（JSON Web Token）是目前最流行的跨域認(rèn)證解決方案，是一種基于Token的認(rèn)證授權(quán)機(jī)制。此外JWT還被廣發(fā)應(yīng)用于單點(diǎn)登陸及信息交換。
Part 01●??JWT是什么？?●
JWT（JSON Web Token）是一個(gè)開放的行業(yè)標(biāo)準(zhǔn)（RFC 7519），自身包含了身份驗(yàn)證所需要的所有信息，因此我們的服務(wù)器不需要存儲(chǔ)用戶Session信息。這顯然增加了系統(tǒng)的可用性和伸縮性，大大減輕了服務(wù)端的壓力。可以看出JWT更符合設(shè)計(jì)RESTful API時(shí)的Stateless（無狀態(tài)）原則。并且使用JWT認(rèn)證可以有效避免CSRF攻擊，因?yàn)镴WT一般是存在在localStorage中，使用JWT進(jìn)行身份驗(yàn)證的過程中是不會(huì)涉及到Cookie的。
Part 02●??JWT由哪些部分組成？?●
JWT本質(zhì)上是一組字串，通常是這樣的：xxxxx.yyyyy.zzzzz，通過（.）切分成三個(gè)為Base64編碼的部分：
Header：描述JWT的元數(shù)據(jù)，定義了生成簽名的算法以及Token的類型。
Payload：用來存放實(shí)際需要傳遞的數(shù)據(jù)。
Signature：服務(wù)器通過Payload、Header和一個(gè)密鑰(Secret)
使用Header里面指定的簽名算法（默認(rèn)是 HMAC SHA256）生成。
示例：
可以通過https://jwt.io對(duì)上述JWT進(jìn)行解碼，解碼之后便可得到Header、Payload、Signature這三部分。Header和Payload都是JSON格式的數(shù)據(jù)，Signature由Payload、Header和Secret(密鑰)通過特定的計(jì)算公式和加密算法得到。
Header
通常由兩部分組成。
typ（Type）：令牌類型，也就是JWT
alg（Algorithm）：簽名算法，比如HS256
示例：
JSON形式的Header被轉(zhuǎn)換成Base64編碼，成為JWT的第一部。
Payload
包含了三種類型的聲明。
Registered Claims（注冊聲明）：預(yù)定義的一些聲明，建議使用，但不強(qiáng)制。
Public Claims（公有聲明）：JWT簽發(fā)方可以自定義的聲明。
Private Claims（私有聲明）：JWT簽發(fā)方因?yàn)轫?xiàng)目需要而自定義的聲明。
下面是一些常見的注冊聲明：
iss（issuer）：JWT 簽發(fā)方。
iat（issued at time）：JWT簽發(fā)時(shí)間。
sub（subject）：JWT主題。
aud（audience）：JWT接收方。
exp（expiration time）：JWT的過期時(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)行用戶認(rèn)證？?●
在基于JWT進(jìn)行身份驗(yàn)證的的應(yīng)用程序中，服務(wù)器通過 Payload、Header和Secret(密鑰)創(chuàng)建JWT并將JWT發(fā)送給客戶端?？蛻舳私邮盏絁WT之后，會(huì)將其保存在Cookie或者localStorage里面，以后客戶端發(fā)出的所有請求都會(huì)攜帶這個(gè)令牌。
簡化后的步驟如下：
1．用戶向服務(wù)器發(fā)送用戶名、密碼以及驗(yàn)證碼用于登陸系統(tǒng)。
2．如果用戶用戶名、密碼以及驗(yàn)證碼校驗(yàn)正確的話，服務(wù)端會(huì)返回已簽名的Token，也就是JWT。
3．用戶以后每次向后端發(fā)請求都在Header中帶上這個(gè)JWT。
4．服務(wù)端檢查JWT并從中獲取用戶相關(guān)信息。
兩點(diǎn)建議：
1．建議將JWT存放在localStorage中，放在Cookie中會(huì)有CSRF風(fēng)險(xiǎn)。
2．請求服務(wù)端并攜帶JWT的常見做法是將其放在HTTP Header的Authorization字段中（Authorization：Bearer Token）
Part 04●?JWT如何防止被篡改？?●
服務(wù)器返回簽名之后，即使JWT被泄露或者截獲，黑客也沒辦法同時(shí)篡改Signature、Header、Payload。
這是為什么呢？因?yàn)榉?wù)端拿到JWT之后，會(huì)解析出其中包含的Header、Payload 以及Signature。服務(wù)端會(huì)根據(jù)Header、Payload、密鑰再次生成一個(gè)Signature。拿新生成的Signature和JWT中的Signature作對(duì)比，如果一樣就說明Header和Payload沒有被修改。
不過，如果服務(wù)端的秘鑰也被泄露的話，黑客就可以同時(shí)篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后，再重新生成一個(gè)Signature就可以了。
?注意：密鑰一定保管好，一定不要泄露出去。JWT安全的核心在于簽名，簽名安全的核心在密鑰。
Part 05●? JWT如何加強(qiáng)安全性？?●
1．使用安全系數(shù)高的加密算法。
2．使用成熟的開源庫，沒必要造輪子。
3．JWT存放在localStorage中而不是Cookie中，避免CSRF風(fēng)險(xiǎn)。
4．一定不要將隱私信息存放在Payload當(dāng)中。
5．密鑰一定保管好，一定不要泄露出去。JWT安全的核心在于簽名，簽名安全的核心在密鑰。
6．Payload要加入exp（JWT的過期時(shí)間），永久有效的JWT不合理。并且JWT的過期時(shí)間不易過長。
Part 06●? JWT有哪些優(yōu)缺點(diǎn)？?●
- 優(yōu)點(diǎn)
1．無狀態(tài)：自身攜帶用戶信息，不需要在服務(wù)器上保存session信息。
2．可有效避免CSRF攻擊：CSRF攻擊需要依賴Cookie，然而JWT選擇存放在localStorage中，因此非法鏈接無法獲取JWT。
- 缺點(diǎn)
1．不可控：就比如說，我們想要在JWT有效期內(nèi)廢棄一個(gè)JWT或者更改它的權(quán)限的話，并不會(huì)立即生效，通常需要等到有效期過后才可以。再比如說，當(dāng)用戶Logout的話，JWT也還有效。
Part 07●? JWT使用總結(jié)?●
在“約定優(yōu)于配置，配置優(yōu)于編碼”的開發(fā)理念下，通過Apollo配置中心，程序員不需要每次更改線上配置都要重新發(fā)布服務(wù)，成功實(shí)現(xiàn)了將配置與編碼解耦，為線上服務(wù)變更配置提供了解決方案。
參考文獻(xiàn)
[1]?https://jwt.io/，2023年09月12日.
[2]??https://www.iana.org/assignments/jwt/jwt.xhtml，2023年09月12日.
[3]?https://zhuanlan.zhihu.com/p/598529592，2023年09月12日.
[4]?https://zhuanlan.zhihu.com/p/86937325，2023年09月13日.
下載ECAD模型
