建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
Labs 導(dǎo)讀
我們?cè)谧鰬?yīng)用系統(tǒng)時(shí)避免不了用戶的認(rèn)證授權(quán)，說(shuō)簡(jiǎn)單點(diǎn)就是：認(rèn)證你是誰(shuí)，授權(quán)你有什么權(quán)限。在這里先來(lái)談?wù)動(dòng)脩舻恼J(rèn)證，目前常用的認(rèn)證方式有兩種：基于session認(rèn)證、基于token認(rèn)證。
Part 01、 JWT是什么？
JWT（JSON Web Token）是一個(gè)開(kāi)放的行業(yè)標(biāo)準(zhǔn)（RFC 7519），自身包含了身份驗(yàn)證所需要的所有信息，因此我們的服務(wù)器不需要存儲(chǔ)用戶Session信息。這顯然增加了系統(tǒng)的可用性和伸縮性，大大減輕了服務(wù)端的壓力。可以看出JWT更符合設(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)中！?。?/p>
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ù)器通過(guò) Payload、Header和Secret(密鑰)創(chuàng)建JWT并將JWT發(fā)送給客戶端?？蛻舳私邮盏絁WT之后，會(huì)將其保存在Cookie或者localStorage里面，以后客戶端發(fā)出的所有請(qǐng)求都會(huì)攜帶這個(gè)令牌。
圖片
簡(jiǎn)化后的步驟如下：
1．用戶向服務(wù)器發(fā)送用戶名、密碼以及驗(yàn)證碼用于登陸系統(tǒng)。
2．如果用戶用戶名、密碼以及驗(yàn)證碼校驗(yàn)正確的話，服務(wù)端會(huì)返回已簽名的Token，也就是JWT。
3．用戶以后每次向后端發(fā)請(qǐng)求都在Header中帶上這個(gè)JWT。
4．服務(wù)端檢查JWT并從中獲取用戶相關(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ù)端的秘鑰也被泄露的話，黑客就可以同時(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)：自身攜帶用戶信息，不需要在服務(wù)器上保存session信息。
2．可有效避免CSRF攻擊：CSRF攻擊需要依賴(lài)Cookie，然而JWT選擇存放在localStorage中，因此非法鏈接無(wú)法獲取JWT。
- 缺點(diǎn)
1．不可控：就比如說(shuō)，我們想要在JWT有效期內(nèi)廢棄一個(gè)JWT或者更改它的權(quán)限的話，并不會(huì)立即生效，通常需要等到有效期過(guò)后才可以。再比如說(shuō)，當(dāng)用戶Logout的話，JWT也還有效。
Part 07、 JWT使用總結(jié)
在“約定優(yōu)于配置，配置優(yōu)于編碼”的開(kāi)發(fā)理念下，通過(guò)Apollo配置中心，程序員不需要每次更改線上配置都要重新發(fā)布服務(wù)，成功實(shí)現(xiàn)了將配置與編碼解耦，為線上服務(wù)變更配置提供了解決方案。
分享名稱(chēng)：一文讀懂JWT
分享網(wǎng)址：http://m.5511xx.com/article/dphpioo.html
