JSON Web Token（JWT）是一個非常輕巧的規(guī)范。這個規(guī)范允許我們使用JWT在用戶和服務(wù)器之間傳遞安全可靠的信息。
讓我們來假想一下一個場景途茫。在A用戶關(guān)注了B用戶的時候，系統(tǒng)發(fā)郵件給B用戶，并且附有一個鏈接“點此關(guān)注A用戶”哆键。鏈接的地址可以是這樣的
https://your.awesome-app.com/make-friend/?from_user=B&target_user=A
上面的URL主要通過URL來描述這個當(dāng)然這樣做有一個弊端，那就是要求用戶B用戶是一定要先登錄的瘦锹〖冢可不可以簡化這個流程，讓B用戶不用登錄就可以完成這個操作弯院。JWT就允許我們做到這點辱士。
上面的URL主要通過URL來描述這個當(dāng)然這樣做有一個弊端，那就是要求用戶B用戶是一定要先登錄的听绳∷痰猓可不可以簡化這個流程，讓B用戶不用登錄就可以完成這個操作椅挣。JWT就允許我們做到這點头岔。
載荷（Payload）
我們先將上面的添加好友的操作描述成一個JSON對象塔拳。其中添加了一些其他的信息，幫助今后收到這個JWT的服務(wù)器理解這個JWT峡竣。
{
"iss": "John Wu JWT",
"iat": 1441593502,
"exp": 1441594722,
"aud": "www.example.com",
"sub": "jrocket@example.com",
"from_user": "B",
"target_user": "A"
}
這里面的前五個字段都是由JWT的標準所定義的靠抑。
- iss: 該JWT的簽發(fā)者
- sub: 該JWT所面向的用戶
- aud: 接收該JWT的一方
- exp(expires): 什么時候過期，這里是一個Unix時間戳
- iat(issued at): 在什么時候簽發(fā)的
將上面的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)))
// 輸出：eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9
小知識：Base64是一種編碼稚伍，也就是說，它是可以被翻譯回原來的樣子來的戚宦。它并不是一種加密過程个曙。
頭部（Header）
JWT還需要一個頭部，頭部用于描述關(guān)于該JWT的最基本的信息受楼，例如其類型以及簽名所用的算法等垦搬。這也可以被表示成一個JSON對象。
{
"typ": "JWT",
"alg": "HS256"
}
在這里艳汽，我們說明了這是一個JWT猴贰，并且我們所用的簽名算法（后面會提到）是HS256算法。
對它也要進行Base64編碼河狐，之后的字符串就成了JWT的Header（頭部）米绕。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
簽名（簽名）
將上面的兩個編碼后的字符串都用句號.連接在一起（頭部在前），就形成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
最后馋艺，我們將上面拼接完的字符串用HS256算法進行加密栅干。在加密的時候，我們還需要提供一個密鑰（secret）捐祠。如果我們用mystar作為密鑰的話碱鳞，那么就可以得到我們加密后的內(nèi)容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
這一部分又叫做簽名。
最后將這一部分簽名也拼接在被簽名的字符串后面踱蛀，我們就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
于是窿给，我們就可以將郵件中的URL改成
https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
這樣就可以安全地完成添加好友的操作了！
且慢率拒，我們一定會有一些問題：
簽名的目的是什么崩泡？
Base64是一種編碼，是可逆的猬膨，那么我的信息不就被暴露了嗎允华？
讓我逐一為你說明。
簽名的目的
最后一步簽名的過程，實際上是對頭部以及載荷內(nèi)容進行簽名靴寂。一般而言，加密算法對于不同的輸入產(chǎn)生的輸出總是不一樣的召耘。對于兩個不同的輸入百炬，產(chǎn)生同樣的輸出的概率極其地小（有可能比我成世界首富的概率還形鬯）剖踊。所以，我們就把“不一樣的輸入產(chǎn)生不一樣的輸出”當(dāng)做必然事件來看待吧衫贬。
所以德澈，如果有人對頭部以及載荷的內(nèi)容解碼之后進行修改，再進行編碼的話固惯，那么新的頭部和載荷的簽名和之前的簽名就將是不一樣的梆造。而且，如果不知道服務(wù)器加密的時候用的密鑰的話葬毫，得出來的簽名也一定會是不一樣的镇辉。
簽名過程
服務(wù)器應(yīng)用在接受到JWT后，會首先對頭部和載荷的內(nèi)容用同一算法再次簽名贴捡。那么服務(wù)器應(yīng)用是怎么知道我們用的是哪一種算法呢忽肛？別忘了，我們在JWT的頭部中已經(jīng)用alg字段指明了我們的加密算法了烂斋。
如果服務(wù)器應(yīng)用對頭部和載荷再次以同樣方法簽名之后發(fā)現(xiàn)屹逛，自己計算出來的簽名和接受到的簽名不一樣，那么就說明這個Token的內(nèi)容被別人動過的汛骂，我們應(yīng)該拒絕這個Token罕模，返回一個HTTP 401 Unauthorized響應(yīng)。
信息會暴露香缺？
是的手销。
所以，在JWT中图张，不應(yīng)該在載荷里面加入任何敏感的數(shù)據(jù)锋拖。在上面的例子中，我們傳輸?shù)氖怯脩舻腢ser ID祸轮。這個值實際上不是什么敏感內(nèi)容兽埃，一般情況下被知道也是安全的。
但是像密碼這樣的內(nèi)容就不能被放在JWT中了适袜。如果將用戶的密碼放在了JWT中柄错，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
JWT的適用場景
我們可以看到，JWT適合用于向Web應(yīng)用傳遞一些非敏感信息售貌。例如在上面提到的完成加好友的操作给猾，還有諸如下訂單的操作等等。
其實JWT還經(jīng)常用于設(shè)計用戶認證和授權(quán)系統(tǒng)颂跨，甚至實現(xiàn)Web應(yīng)用的單點登錄敢伸。在下一次的文章中，我將為大家系統(tǒng)地總結(jié)JWT在用戶認證和授權(quán)上的應(yīng)用恒削。
