摘要：的組成一個(gè)實(shí)際上就是一個(gè)字符串，它由三部分組成，頭部載荷與簽名。這個(gè)字符串我們將它稱作的載荷。注意是一種編碼，它是可以被翻譯回原來(lái)的樣子來(lái)的。這也可以被表示成一個(gè)對(duì)象。

JSON Web Token（JWT）是一個(gè)非常輕巧的規(guī)范。這個(gè)規(guī)范允許我們使用JWT在用戶和服務(wù)器之間傳遞安全可靠的信息。

讓我們來(lái)假想一下一個(gè)場(chǎng)景。在A用戶關(guān)注了B用戶的時(shí)候，系統(tǒng)發(fā)郵件給B用戶，并且附有一個(gè)鏈接“點(diǎn)此關(guān)注A用戶”。鏈接的地址可以是這樣的

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

上面的URL主要通過(guò)URL來(lái)描述這個(gè)當(dāng)然這樣做有一個(gè)弊端，那就是要求用戶B用戶是一定要先登錄的。可不可以簡(jiǎn)化這個(gè)流程，讓B用戶不用登錄就可以完成這個(gè)操作。JWT就允許我們做到這點(diǎn)。

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

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

這里面的前五個(gè)字段都是由JWT的標(biāo)準(zhǔn)所定義的。

iss: 該JWT的簽發(fā)者

sub: 該JWT所面向的用戶

aud: 接收該JWT的一方

exp(expires): 什么時(shí)候過(guò)期，這里是一個(gè)Unix時(shí)間戳

iat(issued at): 在什么時(shí)候簽發(fā)的

這些定義都可以在標(biāo)準(zhǔn)中找到。

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

eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

注意：base64是一種編碼，它是可以被翻譯回原來(lái)的樣子來(lái)的。它并不是一種加密過(guò)程。

頭部（Header）

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

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

在這里，我們說(shuō)明了這是一個(gè)JWT，并且我們所用的簽名算法（后面會(huì)提到）是HS256算法。

對(duì)它也要進(jìn)行Base64編碼，之后的字符串就成了JWT的Header（頭部）。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

簽名（簽名）

將上面的兩個(gè)編碼后的字符串都用句號(hào).連接在一起（頭部在前），就形成了

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

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

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

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

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

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

這樣服務(wù)端驗(yàn)證完JWT的簽名沒(méi)問(wèn)題后就可以完成B用戶添加A用戶為好友的操作而不在需要用戶再進(jìn)行登錄啦。

看到這里你應(yīng)該會(huì)有兩個(gè)疑問(wèn)

簽名的目的是什么？

Base64是一種編碼，是可逆的，那么我的信息不就被暴露了嗎？

簽名的目的

最后一步簽名的過(guò)程，實(shí)際上是對(duì)頭部以及載荷內(nèi)容進(jìn)行簽名。一般而言，加密算法對(duì)于不同的輸入產(chǎn)生的輸出總是不一樣的。對(duì)于兩個(gè)不同的輸入，產(chǎn)生同樣的輸出的概率極其地小。

所以，如果有人對(duì)頭部以及載荷的內(nèi)容解碼之后進(jìn)行修改，再進(jìn)行編碼的話，那么新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務(wù)器加密的時(shí)候用的密鑰的話，得出來(lái)的簽名也一定會(huì)是不一樣的。

服務(wù)器應(yīng)用在接收到JWT后，會(huì)首先對(duì)頭部和載荷的內(nèi)容用同一算法再次簽名。那么服務(wù)器應(yīng)用是怎么知道我們用的是哪一種算法呢？別忘了，我們?cè)贘WT的頭部中已經(jīng)用alg字段指明了我們的加密算法了。

如果服務(wù)器應(yīng)用對(duì)頭部和載荷再次以同樣方法簽名之后發(fā)現(xiàn)，自己計(jì)算出來(lái)的簽名和接受到的簽名不一樣，那么就說(shuō)明這個(gè)Token的內(nèi)容被別人動(dòng)過(guò)的，我們應(yīng)該拒絕這個(gè)Token，返回一個(gè)HTTP 401 Unauthorized響應(yīng)。

關(guān)于兩個(gè)簽名的推薦用PHP中內(nèi)建函數(shù)hash_equals來(lái)幫我們完成

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

信息會(huì)暴露

JWT荷載和頭部中的信息都可以通過(guò)base64解碼拿到，所以在JWT中，不應(yīng)該在載荷里面加入任何敏感的數(shù)據(jù)。在上面的例子中，我們傳輸?shù)氖怯脩舻腢ser ID。這個(gè)值實(shí)際上不是什么敏感內(nèi)容，一般情況下被知道也是安全的。像密碼這樣的內(nèi)容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過(guò)Base64解碼就能很快地知道你的密碼了。

JWT的適用場(chǎng)景

我們可以看到，JWT適合用于向Web應(yīng)用傳遞一些非敏感信息。例如在上面提到的完成加好友的操作，還有就是

JWT還經(jīng)常用于設(shè)計(jì)用戶認(rèn)證和授權(quán)系統(tǒng)，尤其是現(xiàn)在前后端分離開(kāi)發(fā)架構(gòu)下，用戶登錄成功后將攜帶著用戶標(biāo)示和登錄時(shí)間、站點(diǎn)等信息的JWT給到前端，前端在API請(qǐng)求的HEADER頭中攜帶JWT，服務(wù)端驗(yàn)證完JWT的合法性后就能通過(guò)用戶標(biāo)示找到本次API請(qǐng)求所屬的用戶。

之前用PHP寫(xiě)了一個(gè)非常簡(jiǎn)陋的生成和校驗(yàn)JWT的程序，可以拿來(lái)參考，代碼放到gist上了https://gist.github.com/kevin...。