SON 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實際上就是一個字元串，它由三部分組成，頭部、載荷與簽名。
https://blog.didispace.com/json-web-token-web-security/#%E8%BD%BD%E8%8D%B7%EF%BC%88Payload%EF%BC%89 載荷（Payload）
我們先将上面的添加好友的操作描述成一個JSON對象。其中添加了一些其他的資訊，幫助今後收到這個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
-
sub
-
aud
-
exp
-
iat
這些定義都可以在
标準中找到。
将上面的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是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它并不是一種加密過程。
https://blog.didispace.com/json-web-token-web-security/#%E5%A4%B4%E9%83%A8%EF%BC%88Header%EF%BC%89 頭部（Header）
JWT還需要一個頭部，頭部用于描述關于該JWT的最基本的資訊，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象。
{
"typ": "JWT",
"alg": "HS256"
} https://blog.didispace.com/json-web-token-web-security/#%E5%A4%B4%E9%83%A8%EF%BC%88Header%EF%BC%89
JWT還需要一個頭部，頭部用于描述關于該JWT的最基本的資訊，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象
{
"typ": "JWT",
"alg": "HS256"
} 在這裡，我們說明了這是一個JWT，并且我們所用的簽名算法（後面會提到）是HS256算法。
對它也要進行Base64編碼，之後的字元串就成了JWT的Header（頭部）。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 簽名（簽名）
将上面的兩個編碼後的字元串都用句号
.
連接配接在一起（頭部在前），就形成了
這一部分的過程在
node-jws的源碼中有展現
最後，我們将上面拼接完的字元串用HS256算法進行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用
mystar
作為密鑰的話，那麼就可以得到我們加密後的内容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM 這一部分又叫做簽名。
最後将這一部分簽名也拼接在被簽名的字元串後面，我們就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM 于是，我們就可以将郵件中的URL改成
https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM 這樣就可以安全地完成添加好友的操作了！
且慢，我們一定會有一些問題：
- 簽名的目的是什麼？
- Base64是一種編碼，是可逆的，那麼我的資訊不就被暴露了嗎？
讓我逐一為你說明。
https://blog.didispace.com/json-web-token-web-security/#%E7%AD%BE%E5%90%8D%E7%9A%84%E7%9B%AE%E7%9A%84 簽名的目的
最後一步簽名的過程，實際上是對頭部以及載荷内容進行簽名。一般而言，加密算法對于不同的輸入産生的輸出總是不一樣的。對于兩個不同的輸入，産生同樣的輸出的機率極其地小（有可能比我成世界首富的機率還小）。是以，我們就把“不一樣的輸入産生不一樣的輸出”當做必然事件來看待吧。
是以，如果有人對頭部以及載荷的内容解碼之後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和之前的簽名就将是不一樣的。而且，如果不知道伺服器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。
伺服器應用在接受到JWT後，會首先對頭部和載荷的内容用同一算法再次簽名。那麼伺服器應用是怎麼知道我們用的是哪一種算法呢？别忘了，我們在JWT的頭部中已經用
alg
字段指明了我們的加密算法了。
如果伺服器應用對頭部和載荷再次以同樣方法簽名之後發現，自己計算出來的簽名和接受到的簽名不一樣，那麼就說明這個Token的内容被别人動過的，我們應該拒絕這個Token，傳回一個HTTP 401 Unauthorized響應。
https://blog.didispace.com/json-web-token-web-security/#%E4%BF%A1%E6%81%AF%E4%BC%9A%E6%9A%B4%E9%9C%B2%EF%BC%9F 資訊會暴露？
是的。
是以，在JWT中，不應該在載荷裡面加入任何敏感的資料。在上面的例子中，我們傳輸的是使用者的User ID。這個值實際上不是什麼敏感内容，一般情況下被知道也是安全的。
但是像密碼這樣的内容就不能被放在JWT中了。如果将使用者的密碼放在了JWT中，那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
https://blog.didispace.com/json-web-token-web-security/#JWT%E7%9A%84%E9%80%82%E7%94%A8%E5%9C%BA%E6%99%AF JWT的适用場景
我們可以看到，JWT适合用于向Web應用傳遞一些非敏感資訊。例如在上面提到的完成加好友的操作，還有諸如下訂單的操作等等。
其實JWT還經常用于設計使用者認證和授權系統，甚至實作Web應用的單點登入。在下一次的文章中，我将為大家系統地總結JWT在使用者認證和授權上的應用。