JWT 介紹

JSON Web Token(JWT)是一個(gè)開放式標(biāo)準(zhǔn)(RFC 7519)，它定義了一種緊湊(Compact)且自包含(Self-contained)的方式，用于在各方之間以JSON對(duì)象安全傳輸信息。

這些信息可以通過數(shù)字簽名進(jìn)行驗(yàn)證和信任。可以使用秘密(使用HMAC算法)或使用RSA的公鑰/私鑰對(duì)對(duì)JWT進(jìn)行簽名。

雖然JWT可以加密以提供各方之間的保密性，但我們將重點(diǎn)關(guān)注已簽名的令牌。簽名的令牌可以驗(yàn)證其中包含的索賠的完整性，而加密令牌隱藏來自其他方的索賠。

當(dāng)令牌使用公鑰/私鑰對(duì)進(jìn)行簽名時(shí)，簽名還證明只有持有私鑰的方是簽名方。

我們來進(jìn)一步解釋一些概念：

• Compact(緊湊)：由于它們尺寸較小，JWT可以通過URL，POST參數(shù)或HTTP標(biāo)頭內(nèi)發(fā)送。另外，尺寸越小意味著傳輸速度越快。

• Self-contained(自包含):有效載荷(Playload)包含有關(guān)用戶的所有必需信息，避免了多次查詢數(shù)據(jù)庫。

JWT適用場(chǎng)景

• Authentication(鑒權(quán))：

  這是使用JWT最常見的情況。一旦用戶登錄，每個(gè)后續(xù)請(qǐng)求都將包含JWT，允許用戶訪問該令牌允許的路由，服務(wù)和資源。

  單點(diǎn)登錄是當(dāng)今廣泛使用JWT的一項(xiàng)功能，因?yàn)樗拈_銷很小，并且能夠輕松地跨不同域使用。
• Information Exchange(信息交換)：JSON Web Tokens是在各方之間安全傳輸信息的好方式。因?yàn)镴WT可以簽名：例如使用公鑰/私鑰對(duì)，所以可以確定發(fā)件人是他們自稱的人。

  此外，由于使用標(biāo)頭和有效載荷計(jì)算簽名，因此您還可以驗(yàn)證內(nèi)容是否未被篡改。

JWT結(jié)構(gòu)

在緊湊的形式中，JWT包含三個(gè)由點(diǎn)(.)分隔的部分，它們分別是：

• Header

• Payload

• Signature

JWT結(jié)構(gòu)通常如下所示：

xxxxx.yyyyy.zzzzz

下面我們分別來介紹這三個(gè)部分：

Header

Header通常由兩部分組成：令牌的類型，即JWT。和常用的散列算法，如HMAC SHA256或RSA。

例如：

{
??"alg":?"HS256",
??"typ":?"JWT"
}Header部分的JSON被Base64Url編碼，形成JWT的第一部分。

Payload

這里放聲明內(nèi)容，可以說就是存放溝通訊息的地方，在定義上有3種聲明(Claims)：

• Registered claims(注冊(cè)聲明):這些是一組預(yù)先定義的聲明，它們不是強(qiáng)制性的，但推薦使用，以提供一組有用的，可互操作的聲明。其中一些是：iss(發(fā)行者)，exp(到期時(shí)間)，sub(主題)，aud(受眾)等。#Registered Claim Names#https://tools.ietf.org/html/rfc7519#section-4.1

• Public claims(公開聲明):這些可以由使用JWT的人員隨意定義。但為避免沖突，應(yīng)在IANA JSON Web令牌注冊(cè)表中定義它們，或?qū)⑵涠x為包含防沖突命名空間的URI。
• Private claims(私有聲明):

  這些是為了同意使用它們但是既沒有登記，也沒有公開聲明的各方之間共享信息，而創(chuàng)建的定制聲明。

Playload示例如下：

{
??"sub":?"1234567890",
??"name":?"John?Doe",
??"admin":?true
}Playload部分的JSON被Base64Url編碼，形成JWT的第二部分。

Notice:

請(qǐng)注意，對(duì)于已簽名的令牌，此信息盡管受到篡改保護(hù)，但任何人都可以閱讀。除非加密，否則不要將秘密信息放在JWT的有效內(nèi)容或標(biāo)題元素中。這也是很多文章爭(zhēng)論jwt安全性原因，不要用 JWT 取代 Server-side 的 Session狀態(tài)機(jī)制。詳情請(qǐng)閱讀這篇文章：Stop Using Jwt For Sessions.

Signature

第三部分signature用來驗(yàn)證發(fā)送請(qǐng)求者身份，由前兩部分加密形成。
要?jiǎng)?chuàng)建簽名部分，您必須采用編碼標(biāo)頭，編碼有效載荷，秘鑰，標(biāo)頭中指定的算法并簽名。

例如，如果你想使用HMAC SHA256算法，簽名將按照以下方式創(chuàng)建：

HMACSHA256(
??base64UrlEncode(header)?+?"."?+
??base64UrlEncode(payload),
??secret)

JWT實(shí)踐

JWT輸出的是三個(gè)由點(diǎn)分隔的Base64-URL字符串，可以在HTML和HTTP環(huán)境中輕松傳遞，而與基于XML的標(biāo)準(zhǔn)(如SAML)相比，它更加緊湊。

以下JWT示例，它具有先前的標(biāo)頭和有效負(fù)載編碼，并且使用秘鑰進(jìn)行簽名。

我們可以使用jwt.io調(diào)試器來解碼，驗(yàn)證和生成JWT：

JWT工作原理

在身份驗(yàn)證中，當(dāng)用戶使用他們的憑證成功登錄時(shí)，JSON Web Token將被返回并且必須保存在本地(通常在本地存儲(chǔ)中，但也可以使用Cookie)，而不是在傳統(tǒng)方法中創(chuàng)建會(huì)話 服務(wù)器并返回一個(gè)cookie。關(guān)于存儲(chǔ)令牌(Token)的方式，必須考慮安全因素。
參考：?#Where to Store Tokens#https://auth0.com/docs/tokens/concepts/token-storage

無論何時(shí)用戶想要訪問受保護(hù)的路由或資源，用戶代理都應(yīng)使用承載方案發(fā)送JWT，通常在請(qǐng)求頭中的Authorization字段，使用Bearer schema：

Authorization:?Bearer?這是一種無狀態(tài)身份驗(yàn)證機(jī)制，因?yàn)橛脩魻顟B(tài)永遠(yuǎn)不會(huì)保存在服務(wù)器內(nèi)存中。服務(wù)器受保護(hù)的路由將在授權(quán)頭中檢查有效的JWT，如果存在，則允許用戶訪問受保護(hù)的資源。由于JWT是獨(dú)立的，所有必要的信息都在那里，減少了多次查詢數(shù)據(jù)庫的需求。這使得我們可以完全依賴無狀態(tài)的數(shù)據(jù)API，甚至向下游服務(wù)提出請(qǐng)求。無論哪些域正在為API提供服務(wù)并不重要，因此不會(huì)出現(xiàn)跨域資源共享(CORS)的問題，因?yàn)樗皇褂肅ookie。

Notice:

請(qǐng)注意，使用已簽名的令牌，令牌中包含的所有信息都會(huì)暴露給用戶或其他方，即使他們無法更改它。在JWT中，不應(yīng)該在Playload里面加入任何敏感的數(shù)據(jù),比如像密碼這樣的內(nèi)容。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

常見問題

① JWT 安全嗎?

Base64編碼方式是可逆的，也就是透過編碼后發(fā)放的Token內(nèi)容是可以被解析的。一般而言，我們都不建議在有效載荷內(nèi)放敏感訊息，比如使用者的密碼。

② JWT Payload 內(nèi)容可以被偽造嗎？

JWT其中的一個(gè)組成內(nèi)容為Signature，可以防止通過Base64可逆方法回推有效載荷內(nèi)容并將其修改。因?yàn)镾ignature是經(jīng)由Header跟Payload一起B(yǎng)ase64組成的。

③ 如果我的 Cookie 被竊取了，那不就表示第三方可以做 CSRF 攻擊?

是的，Cookie丟失，就表示身份就可以被偽造。故官方建議的使用方式是存放在LocalStorage中，并放在請(qǐng)求頭中發(fā)送。

④ 空間及長(zhǎng)度問題？

JWT Token通常長(zhǎng)度不會(huì)太小，特別是Stateless JWT Token，把所有的數(shù)據(jù)都編在Token里，很快的就會(huì)超過Cookie的大小(4K)或者是URL長(zhǎng)度限制。

⑤ Token失效問題？

• 無狀態(tài)JWT令牌(Stateless JWT Token)發(fā)放出去之后，不能通過服務(wù)器端讓令牌失效，必須等到過期時(shí)間過才會(huì)失去效用。

• 假設(shè)在這之間Token被攔截，或者有權(quán)限管理身份的差異造成授權(quán)Scope修改，都不能阻止發(fā)出去的Token失效并要求使用者重新請(qǐng)求新的Token。

JWT使用建議

• 不要存放敏感信息在Token里。

• Payload中的exp時(shí)效不要設(shè)定太長(zhǎng)。

• 開啟Only Http預(yù)防XSS攻擊。

• 如果擔(dān)心重播攻擊(replay attacks )可以增加jti(JWT ID)，exp(有效時(shí)間) Claim。

• 在你的應(yīng)用程序應(yīng)用層中增加黑名單機(jī)制，必要的時(shí)候可以進(jìn)行Block做阻擋(這是針對(duì)掉令牌被第三方使用竊取的手動(dòng)防御)。

---

[1] Stop using JWT for sessions：
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

[3] Use JWT The Right Way!:
https://stormpath.com/blog/jwt-the-right-way

[2] JSON Web Token 維基百科：
https://en.wikipedia.org/wiki/JSON_Web_Token

---

作者：mantou叔叔

博客園文章地址：?

cnblogs.com/mantoudev/p/8994341.html

• 如何實(shí)現(xiàn)一個(gè)短鏈接服務(wù)
• 【領(lǐng)導(dǎo)力】論理想中的技術(shù)團(tuán)隊(duì)
• 基于 token 的多平臺(tái)身份認(rèn)證架構(gòu)設(shè)計(jì)
• 九年程序人生的技術(shù)學(xué)習(xí)之路
• 大齡開發(fā)人員如何破局

總結(jié)

以上是生活随笔為你收集整理的jwt token 太长_理解 JWT 鉴权的应用场景及使用建议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。