JWT你知道是什麼嗎

JSON Web Token（JWT）是一個非常輕巧的規範。這個規範允許我們使用JWT在用戶和服務器之間傳遞安全可靠的信息。

讓我們來假想一下一個場景。在A用戶關注了B用戶的時候，系統發郵件給B用戶，並且附有一個鏈接“點此關注A用戶”。鏈接的地址可以是這樣的

https://your.app.com/make-friend/?from_user=B&target_user=A

上面的URL主要通過URL來描述這個當然這樣做有一個弊端，那就是要求用戶B用戶是一定要先登錄的。可不可以簡化這個流程，讓B用戶不用登錄就可以完成這個操作。JWT就允許我們做到這點。

JWT的組成

一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。

{
 "iss": "John Wu JWT",
 "iat": 1441593502,
 "exp": 1441594722,
 "aud": "www.example.com,
 "sub": "[email protected]",
 "from_user": "B",
 "target_user": "A"
}

這裡面的前五個字段都是由JWT的標準所定義的。

• iss: 該JWT的簽發者
• sub: 該JWT所面向的用戶
• aud: 接收該JWT的一方
• exp(expires): 什麼時候過期，這裡是一個Unix時間戳
• iat(issued at): 在什麼時候簽發的

這些定義都可以在標準中找到。

將上面的JSON對象進行[base64編碼]可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload（載荷）。

eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

注意：base64是一種編碼，它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。

頭部（Header）

JWT還需要一個頭部，頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象。

{
"typ": "JWT",
"alg": "HS256"
}

在這裡，我們說明了這是一個JWT，並且我們所用的簽名算法（後面會提到）是HS256算法。

對它也要進行Base64編碼，之後的字符串就成了JWT的Header（頭部）。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

簽名（簽名）

將上面的兩個編碼後的字符串都用句號.連接在一起（頭部在前），就形成了

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

最後，我們將上面拼接完的字符串($input)用HS256算法($algo)進行加密。在加密的時候，我們還需要提供一個密鑰（$secret）。比方我們使用字符串mySecret作為密鑰的話，那麼就可以通過下面的方法得到我們加密後的內容作為JWT的簽名:

hash_hmac($algo, $input, $secret);// output:rSWamyAYwuHCo7IFAgd1oRpùSP7nzL7BF5t7ItqpKViM

最後將這一部分簽名也拼接在被簽名的字符串後面，我們就得到了完整的JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

於是，我們就可以將郵件中的URL改成

https://your.app.com/make-fri...
 

這樣服務端驗證完JWT的簽名沒問題後就可以完成B用戶添加A用戶為好友的操作而不在需要用戶再進行登錄啦。

看到這裡你應該會有兩個疑問

• 簽名的目的是什麼？
• Base64是一種編碼，是可逆的，那麼我的信息不就被暴露了嗎？

簽名的目的

最後一步簽名的過程，實際上是對頭部以及載荷內容進行簽名。一般而言，加密算法對於不同的輸入產生的輸出總是不一樣的。對於兩個不同的輸入，產生同樣的輸出的概率極其地小。

所以，如果有人對頭部以及載荷的內容解碼之後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。

服務器應用在接收到JWT後，會首先對頭部和載荷的內容用同一算法再次簽名。那麼服務器應用是怎麼知道我們用的是哪一種算法呢？別忘了，我們在JWT的頭部中已經用alg字段指明瞭我們的加密算法了。

如果服務器應用對頭部和載荷再次以同樣方法簽名之後發現，自己計算出來的簽名和接受到的簽名不一樣，那麼就說明這個Token的內容被別人動過的，我們應該拒絕這個Token，返回一個HTTP 401 Unauthorized響應。

關於兩個簽名的推薦用PHP中內建函數hash_equals來幫我們完成

hash_equals ( string $known_string , string $user_string ) : bool
比較兩個字符串，無論它們是否相等，本函數的時間消耗是恆定的。
本函數可以用在需要防止時序攻擊的字符串比較場景中， 例如，可以用在比較 crypt() 密碼哈希值的場景。

信息會暴露

JWT荷載和頭部中的信息都可以通過base64解碼拿到，所以在JWT中，不應該在載荷裡面加入任何敏感的數據。在上面的例子中，我們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容，一般情況下被知道也是安全的。像密碼這樣的內容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

JWT的適用場景

我們可以看到，JWT適合用於向Web應用傳遞一些非敏感信息。例如在上面提到的完成加好友的操作，還有就是JWT還經常用於設計用戶認證和授權系統，尤其是現在前後端分離開發架構下，用戶登錄成功後將攜帶著用戶標示和登錄時間、站點等信息的JWT給到前端，前端在API請求的HEADER頭中攜帶JWT，服務端驗證完JWT的合法性後就能通過用戶標示找到本次API請求所屬的用戶。