深入淺出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 )