JWT必知必會

最近，項目的安全認證機制全面採用JWT。如今，趁整個工做基本告一段落之際，將一些知識點總結一下發布出來。

爲何要遷移？

緣由很簡單，就如下幾點：

• 爲了遷移到微服務架構，因爲服務分拆以後，單一的登陸入口點消失了，採用Token是必然之選。
• 爲了伸縮性考慮，採用Cookie + Session機制，必然面臨着應用狀態的問題，並且必然牽涉到session的複製。採用Token，自然避免這一點。這裏並不是是指徹底無Session化，但起碼能夠降至最少。
• 爲了移動端考慮，Token更適合移動端，比Cookie更靈活了。
• 爲了安全性考慮，Token機制【僅驗證request header時】自然對CSRF免疫。

JWT爲什麼物？

JWT由三部分組成：header + payload + signature，每部分是一個Json表示。最終的Token對這三部分進行編碼以後的字符串，中間用「.」分割：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) # token is now: 
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

在應用與服務器之間傳遞的就是上述字符串形式的Token。

如何使用JWT？

使用JWT的應用基本都遵循下面的使用流程：

1. 訪問登陸點。
2. 登陸服務驗證以後，簽發證書返回給客戶端。
3. 客戶端保存證書，並在每次請求時將其附在request header中，表示已經登陸。
4. 服務器接收請求以後，經過簽名和時戳，驗證Token的有效性。
5. 如有效，則響應客戶端。

對應的request header以下：

Authorization:Bearer <token>

整個過程以下圖：

在通常的應用中，驗證成功以後，服務器可能會在Cookie或Session中保留一些用戶相關的額外信息，簡化後續的編程，同時避免反覆讀取數據庫。

在JWT，一樣能夠實現這樣的功能：只需將相應的內容放入payload便可。這樣，下次從客戶端發送的token中即可以解碼得出。

驗證JWT的有效性時，會考慮至少下面兩點：

1. 簽名是否正確？
2. Token是否到期？

整個過程的編碼其實並不複雜，請參見文後的連接，這裏再也不囉嗦。

使用中的注意事項

出於安全性，注意如下幾點：

• 簽名證書須要安全存放
• 不要將敏感信息放置於token中
• 請結合SSL使用

• 若是要在Cookie中保存Token【此時，服務器要同時驗證cookie或header中是否有token】

  • 留意Token的大小超過Cookie的限制
  • 請使用HttpOnly標誌。如有可能，使用Secure標誌。
  • 採用Synchronize Token來防止CSRF【這是由於，在A站點上發起向B站點的請求時，B站點的Cookie一樣會被髮送給B。若不使用另外一個Token來防禦，則沒法得知cookie中的JWT是否屬於從A->B，仍是從B->B。目前，大部分現有的框架已經支持】。
• 爲了防止replay attack，可加上jti、exp和iat聲明

以上是對JWT的旋風式說明，其餘的內容，請參見參考文獻。

參考文獻

• Get Started with JSON Web Tokens
• Introduction to JSON Web Tokens
• 維基百科上的JWT
• Vert.x Web的JWT例子
• Where to Store your JWTs – Cookies vs HTML5 Web Storage
• Use JWT The Right Way!
• Authentication: Cookies vs JWTs and why you’re doing it wrong
• How to store a JWT token inside an HTTP only cookie?
• Cookies vs Tokens: The Definitive Guide
• 管理JWT的生命週期
• JWT規範