深入淺出JWT(JSON Web Token )
1. JWT 介紹
JSON Web Token(JWT)是一個開放式標準(RFC 7519),它定義了一種緊湊(Compact)且自包含(Self-contained)的方式,用於在各方之間以JSON對象安全傳輸信息。 這些信息可以通過數字簽名進行驗證和信任。 可以使用秘密(使用HMAC算法)或使用RSA的公鑰/私鑰對對JWT進行簽名。
雖然JWT可以加密以提供各方之間的保密性,但我們將重點關註已簽名的令牌。 簽名的令牌可以驗證其中包含的索賠的完整性,而加密令牌隱藏來自其他方的索賠。 當令牌使用公鑰/私鑰對進行簽名時,簽名還證明只有持有私鑰的方是簽名方。
我們來進一步解釋一些概念:
- Compact(緊湊)
由於它們尺寸較小,JWT可以通過URL,POST參數或HTTP標頭內發送。 另外,尺寸越小意味著傳輸速度越快。 - Self-contained(自包含):
有效載荷(Playload)包含有關用戶的所有必需信息,避免了多次查詢數據庫。
2. JWT適用場景
- Authentication(鑒權):
這是使用JWT最常見的情況。 一旦用戶登錄,每個後續請求都將包含JWT,允許用戶訪問該令牌允許的路由,服務和資源。 單點登錄是當今廣泛使用JWT的一項功能,因為它的開銷很小,並且能夠輕松地跨不同域使用。 - Information Exchange(信息交換):
JSON Web Tokens是在各方之間安全傳輸信息的好方式。 因為JWT可以簽名:例如使用公鑰/私鑰對,所以可以確定發件人是他們自稱的人。 此外,由於使用標頭和有效載荷計算簽名,因此您還可以驗證內容是否未被篡改。
3. JWT結構
在緊湊的形式中,JWT包含三個由點(.)分隔的部分,它們分別是:
- Header
- Payload
- Signature
JWT結構通常如下所示:
xxxxx.yyyyy.zzzzz
下面我們分別來介紹這三個部分:
Header
Header通常由兩部分組成:令牌的類型,即JWT。和常用的散列算法,如HMAC SHA256或RSA。
例如:
{
"alg": "HS256",
"typ": "JWT"
}
Header部分的JSON被Base64Url編碼,形成JWT的第一部分。
Payload
這裏放聲明內容,可以說就是存放溝通訊息的地方,在定義上有3種聲明(Claims):
Registered claims(註冊聲明):
這些是一組預先定義的聲明,它們不是強制性的,但推薦使用,以提供一組有用的,可互操作的聲明。 其中一些是:iss
(發行者),exp
(到期時間),sub
(主題),aud
(受眾)等。#Registered Claim Names#- Public claims(公開聲明):
這些可以由使用JWT的人員隨意定義。 但為避免沖突,應在IANA JSON Web令牌註冊表中定義它們,或將其定義為包含防沖突命名空間的URI。 Private claims(私有聲明):
這些是為了同意使用它們但是既沒有登記,也沒有公開聲明的各方之間共享信息,而創建的定制聲明。
Playload示例如下:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Playload部分的JSON被Base64Url編碼,形成JWT的第二部分。
Notice:
請註意,對於已簽名的令牌,此信息盡管受到篡改保護,但任何人都可以閱讀。 除非加密,否則不要將秘密信息放在JWT的有效內容或標題元素中。這也是很多文章爭論jwt安全性原因,不要用 JWT 取代 Server-side 的 Session狀態機制。詳情請閱讀這篇文章:Stop Using Jwt For Sessions.
Signature
第三部分signature用來驗證發送請求者身份,由前兩部分加密形成。
要創建簽名部分,您必須采用編碼標頭,編碼有效載荷,秘鑰,標頭中指定的算法並簽名。
例如,如果你想使用HMAC SHA256算法,簽名將按照以下方式創建:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
3. JWT實踐
JWT輸出的是三個由點分隔的Base64-URL字符串,可以在HTML和HTTP環境中輕松傳遞,而與基於XML的標準(如SAML)相比,它更加緊湊。
以下JWT示例,它具有先前的標頭和有效負載編碼,並且使用秘鑰進行簽名。
我們可以使用jwt.io調試器來解碼,驗證和生成JWT:
4.JWT工作原理
在身份驗證中,當用戶使用他們的憑證成功登錄時,JSON Web Token將被返回並且必須保存在本地(通常在本地存儲中,但也可以使用Cookie),而不是在傳統方法中創建會話 服務器並返回一個cookie。
關於存儲令牌(Token)的方式,必須考慮安全因素。
參考: #Where to Store Tokens#
無論何時用戶想要訪問受保護的路由或資源,用戶代理都應使用承載方案發送JWT,通常在請求頭中的Authorization
字段,使用Bearer
schema:
Authorization: Bearer <token>
這是一種無狀態身份驗證機制,因為用戶狀態永遠不會保存在服務器內存中。 服務器受保護的路由將在授權頭中檢查有效的JWT,如果存在,則允許用戶訪問受保護的資源。 由於JWT是獨立的,所有必要的信息都在那裏,減少了多次查詢數據庫的需求。
這使得我們可以完全依賴無狀態的數據API,甚至向下遊服務提出請求。 無論哪些域正在為API提供服務並不重要,因此不會出現跨域資源共享(CORS)的問題,因為它不使用Cookie。
Notice:
請註意,使用已簽名的令牌,令牌中包含的所有信息都會暴露給用戶或其他方,即使他們無法更改它。 在JWT中,不應該在Playload裏面加入任何敏感的數據,比如像密碼這樣的內容。如果將用戶的密碼放在了JWT中,那麽懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
5. 常見問題
① JWT 安全嗎?
Base64編碼方式是可逆的,也就是透過編碼後發放的Token內容是可以被解析的。一般而言,我們都不建議在有效載荷內放敏感訊息,比如使用者的密碼。
② JWT Payload 內容可以被偽造嗎?
JWT其中的一個組成內容為Signature,可以防止通過Base64可逆方法回推有效載荷內容並將其修改。因為Signature是經由Header跟Payload一起Base64組成的。
③ 如果我的 Cookie 被竊取了,那不就表示第三方可以做 CSRF 攻擊?
是的,Cookie丟失,就表示身份就可以被偽造。故官方建議的使用方式是存放在LocalStorage中,並放在請求頭中發送。
④ 空間及長度問題?
JWT Token通常長度不會太小,特別是Stateless JWT Token,把所有的數據都編在Token裏,很快的就會超過Cookie的大小(4K)或者是URL長度限制。
⑤ Token失效問題?
- 無狀態JWT令牌(Stateless JWT Token)發放出去之後,不能通過服務器端讓令牌失效,必須等到過期時間過才會失去效用。
- 假設在這之間Token被攔截,或者有權限管理身份的差異造成授權Scope修改,都不能阻止發出去的Token失效並要求使用者重新請求新的Token。
6. JWT使用建議
- 不要存放敏感信息在Token裏。
- Payload中的
exp
時效不要設定太長。 - 開啟
Only Http
預防XSS攻擊。 - 如果擔心重播攻擊(replay attacks )可以增加
jti
(JWT ID),exp
(有效時間) Claim。 - 在你的應用程序應用層中增加黑名單機制,必要的時候可以進行Block做阻擋(這是針對掉令牌被第三方使用竊取的手動防禦)。
[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
深入淺出JWT(JSON Web Token )