深刻淺出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