JWT - 在Web應用間安全地傳遞信息

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

讓咱們來假想一下一個場景。在A用戶關注了B用戶的時候，系統發郵件給B用戶，而且附有一個連接「點此關注A用戶」。連接的地址能夠是這樣的

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

上面的URL主要經過URL來描述這個固然這樣作有一個弊端，那就是要求用戶B用戶是必定要先登陸的。可不能夠簡化這個流程，讓B用戶不用登陸就能夠完成這個操做。JWT就容許咱們作到這點。

JWT的組成

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

載荷（Payload）

咱們先將上面的添加好友的操做描述成一個JSON對象。其中添加了一些其餘的信息，幫助從此收到這個JWT的服務器理解這個JWT。

{
    "iss": "John Wu JWT",
    "iat": 1441593502,
    "exp": 1441594722,
    "aud": "www.example.com",
    "sub": "jrocket@example.com",
    "from_user": "B",
    "target_user": "A"
}

 

• iss: 該JWT的簽發者這裏面的前五個字段都是由JWT的標準所定義的。
• sub: 該JWT所面向的用戶
• aud: 接收該JWT的一方
• exp(expires): 何時過時，這裏是一個Unix時間戳
• iat(issued at): 在何時簽發的

payload中能夠放置三類數據：系統保留的、公共的和私有的：

• 系統保留的聲明（Reserved claims）：這類聲明不是必須的，可是是建議使用的，包括：iss (簽發者), exp (過時時間),
  sub (主題), aud (目標受衆)等。這裏咱們發現都用的縮寫的三個字符，這是因爲JWT的目標就是儘量小巧。
• 公共聲明：這類聲明須要在 IANA JSON Web Token Registry 中定義或者提供一個URI，由於要避免重名等衝突。
• 私有聲明：這個就是你根據業務須要本身定義的數據了。如： "from_user": "B"

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

將上面的JSON對象進行[base64編碼]能夠獲得下面的字符串。這個字符串咱們將它稱做JWT的Payload（載荷）。

eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

若是你使用Node.js，能夠用Node.js的包base64url來獲得這個字符串。

var base64url = require('base64url')
var header = {
    "from_user": "B",
    "target_user": "A"
}
console.log(base64url(JSON.stringify(header)))
// 輸出：eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0=

 

頭部（Header）

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

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

對它也要進行Base64編碼，以後的字符串就成了JWT的Header（頭部）。在這裏，咱們說明了這是一個JWT，而且咱們所用的簽名算法（後面會提到）是HS256算法。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ

 

簽名（簽名）

 

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

最後，咱們將上面拼接完的字符串用HS256算法進行加密。在加密的時候，咱們還須要提供一個密鑰（secret）。若是咱們用mystar做爲密鑰的話，那麼就能夠獲得咱們加密後的內容這一部分的過程在node-jws的源碼中有體現

rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

這一部分又叫作簽名。

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

因而，咱們就能夠將郵件中的URL改爲

https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

且慢，咱們必定會有一些問題：這樣就能夠安全地完成添加好友的操做了！

1. 簽名的目的是什麼？
2. Base64是一種編碼，是可逆的，那麼個人信息不就被暴露了嗎？

讓我逐一爲你說明。

簽名的目的

最後一步簽名的過程，其實是對頭部以及載荷內容進行簽名。通常而言，加密算法對於不一樣的輸入產生的輸出老是不同的。對於兩個不一樣的輸入，產生一樣的輸出的機率極其地小（有可能比我成世界首富的機率還小）。因此，咱們就把「不同的輸入產生不同的輸出」當作必然事件來看待吧。

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

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

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

信息會暴露？

是的。

因此，在JWT中，不該該在載荷裏面加入任何敏感的數據。在上面的例子中，咱們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容，通常狀況下被知道也是安全的。

可是像密碼這樣的內容就不能被放在JWT中了。若是將用戶的密碼放在了JWT中，那麼懷有惡意的第三方經過Base64解碼就能很快地知道你的密碼了。

JWT的適用場景

咱們能夠看到，JWT適合用於向Web應用傳遞一些非敏感信息。例如在上面提到的完成加好友的操做，還有諸以下訂單的操做等等。

其實JWT還常常用於設計用戶認證和受權系統，甚至實現Web應用的單點登陸。在下一次的文章中，我將爲你們系統地總結JWT在用戶認證和受權上的應用。若是想要及時地收到下一篇文章的更新，您能夠在下方訂閱個人半月刊：）