8 張漫畫圖解單點(diǎn)登錄系統(tǒng)
不點(diǎn)藍(lán)字關(guān)注，我們哪來故事？
?正文如下?
JSON Web Token（JWT）是一個非常輕巧的規(guī)范。這個規(guī)范允許我們使用JWT在用戶和服務(wù)器之間傳遞安全可靠的信息。
讓我們來假想一下一個場景。在A用戶關(guān)注了B用戶的時候，系統(tǒng)發(fā)郵件給B用戶，并且附有一個鏈接“點(diǎn)此關(guān)注A用戶”。鏈接的地址可以是這樣的
https://your.awesome-app.com/make-friend/?from_user=B&target_user=A上面的URL主要通過URL來描述這個當(dāng)然這樣做有一個弊端，那就是要求用戶B用戶是一定要先登錄的?？刹豢梢院喕@個流程，讓B用戶不用登錄就可以完成這個操作。JWT就允許我們做到這點(diǎn)。
JWT的組成
一個JWT實(shí)際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。
載荷（Payload）
我們先將上面的添加好友的操作描述成一個JSON對象。其中添加了一些其他的信息，幫助今后收到這個JWT的服務(wù)器理解這個JWT。
{
????"iss":?"John?Wu?JWT",
????"iat":?1441593502,
????"exp":?1441594722,
????"aud":?"www.example.com",
????"sub":?"[email protected]",
????"from_user":?"B",
????"target_user":?"A"
}這里面的前五個字段都是由JWT的標(biāo)準(zhǔn)所定義的。
iss: 該JWT的簽發(fā)者 sub: 該JWT所面向的用戶 aud: 接收該JWT的一方 exp(expires): 什么時候過期，這里是一個Unix時間戳 iat(issued at): 在什么時候簽發(fā)的 這些定義都可以在標(biāo)準(zhǔn)中找到。
將上面的JSON對象進(jìn)行[base64編碼]可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload（載荷）。
eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdW如果你使用Node.js，可以用Node.js的包base64url來得到這個字符串。
小知識：Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它并不是一種加密過程。
var?base64url?=?require('base64url')
var?header?=?{
????"from_user":?"B",
????"target_user":?"A"
}
console.log(base64url(JSON.stringify(header)))
//?輸出：eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9
頭部（Header）
JWT還需要一個頭部，頭部用于描述關(guān)于該JWT的最基本的信息，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象。
{
??"typ":?"JWT",
??"alg":?"HS256"
}
在這里，我們說明了這是一個JWT，并且我們所用的簽名算法（后面會提到）是HS256算法。
對它也要進(jìn)行Base64編碼，之后的字符串就成了JWT的Header（頭部）。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
JWT還需要一個頭部，頭部用于描述關(guān)于該JWT的最基本的信息，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象。
{
??"typ":?"JWT",
??"alg":?"HS256"
}在這里，我們說明了這是一個JWT，并且我們所用的簽名算法（后面會提到）是HS256算法。
對它也要進(jìn)行Base64編碼，之后的字符串就成了JWT的Header（頭部）。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
簽名（簽名）
將上面的兩個編碼后的字符串都用句號.連接在一起（頭部在前），就形成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
這一部分的過程在node-jws的源碼中有體現(xiàn)
最后，我們將上面拼接完的字符串用HS256算法進(jìn)行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用mystar作為密鑰的話，那么就可以得到我們加密后的內(nèi)容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
這一部分又叫做簽名。
最后將這一部分簽名也拼接在被簽名的字符串后面，我們就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn
于是，我們就可以將郵件中的URL改成
https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJm
這樣就可以安全地完成添加好友的操作了！
且慢，我們一定會有一些問題：
簽名的目的是什么？ Base64是一種編碼，是可逆的，那么我的信息不就被暴露了嗎？
讓我逐一為你說明。
將上面的兩個編碼后的字符串都用句號.連接在一起（頭部在前），就形成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0這一部分的過程在node-jws的源碼中有體現(xiàn)
最后，我們將上面拼接完的字符串用HS256算法進(jìn)行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用mystar作為密鑰的話，那么就可以得到我們加密后的內(nèi)容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM這一部分又叫做簽名。
最后將這一部分簽名也拼接在被簽名的字符串后面，我們就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn于是，我們就可以將郵件中的URL改成
https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJm這樣就可以安全地完成添加好友的操作了！
且慢，我們一定會有一些問題：
簽名的目的是什么？ Base64是一種編碼，是可逆的，那么我的信息不就被暴露了嗎？ 讓我逐一為你說明。
簽名的目的
最后一步簽名的過程，實(shí)際上是對頭部以及載荷內(nèi)容進(jìn)行簽名。一般而言，加密算法對于不同的輸入產(chǎn)生的輸出總是不一樣的。對于兩個不同的輸入，產(chǎn)生同樣的輸出的概率極其地?。ㄓ锌赡鼙任页墒澜缡赘坏母怕蔬€?。?。所以，我們就把“不一樣的輸入產(chǎn)生不一樣的輸出”當(dāng)做必然事件來看待吧。
所以，如果有人對頭部以及載荷的內(nèi)容解碼之后進(jìn)行修改，再進(jìn)行編碼的話，那么新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務(wù)器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。
服務(wù)器應(yīng)用在接受到JWT后，會首先對頭部和載荷的內(nèi)容用同一算法再次簽名。那么服務(wù)器應(yīng)用是怎么知道我們用的是哪一種算法呢？別忘了，我們在JWT的頭部中已經(jīng)用alg字段指明了我們的加密算法了。
搜索公眾號Java后端棧后臺回復(fù)“面試”，送你一份驚喜禮包。
如果服務(wù)器應(yīng)用對頭部和載荷再次以同樣方法簽名之后發(fā)現(xiàn)，自己計算出來的簽名和接受到的簽名不一樣，那么就說明這個Token的內(nèi)容被別人動過的，我們應(yīng)該拒絕這個Token，返回一個HTTP 401 Unauthorized響應(yīng)。
最后一步簽名的過程，實(shí)際上是對頭部以及載荷內(nèi)容進(jìn)行簽名。一般而言，加密算法對于不同的輸入產(chǎn)生的輸出總是不一樣的。對于兩個不同的輸入，產(chǎn)生同樣的輸出的概率極其地?。ㄓ锌赡鼙任页墒澜缡赘坏母怕蔬€?。?。所以，我們就把“不一樣的輸入產(chǎn)生不一樣的輸出”當(dāng)做必然事件來看待吧。
所以，如果有人對頭部以及載荷的內(nèi)容解碼之后進(jìn)行修改，再進(jìn)行編碼的話，那么新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務(wù)器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。
服務(wù)器應(yīng)用在接受到JWT后，會首先對頭部和載荷的內(nèi)容用同一算法再次簽名。那么服務(wù)器應(yīng)用是怎么知道我們用的是哪一種算法呢？別忘了，我們在JWT的頭部中已經(jīng)用alg字段指明了我們的加密算法了。
搜索公眾號Java后端棧后臺回復(fù)“面試”，送你一份驚喜禮包。
如果服務(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。這個值實(shí)際上不是什么敏感內(nèi)容，一般情況下被知道也是安全的。
但是像密碼這樣的內(nèi)容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
是的。
所以，在JWT中，不應(yīng)該在載荷里面加入任何敏感的數(shù)據(jù)。在上面的例子中，我們傳輸?shù)氖怯脩舻腢ser ID。這個值實(shí)際上不是什么敏感內(nèi)容，一般情況下被知道也是安全的。
但是像密碼這樣的內(nèi)容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中，那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
JWT的適用場景
我們可以看到，JWT適合用于向Web應(yīng)用傳遞一些非敏感信息。例如在上面提到的完成加好友的操作，還有諸如下訂單的操作等等。
我們可以看到，JWT適合用于向Web應(yīng)用傳遞一些非敏感信息。例如在上面提到的完成加好友的操作，還有諸如下訂單的操作等等。
用戶認(rèn)證八步走
所謂用戶認(rèn)證（Authentication），就是讓用戶登錄，并且在接下來的一段時間內(nèi)讓用戶訪問網(wǎng)站時可以使用其賬戶，而不需要再次登錄的機(jī)制。
小知識：可別把用戶認(rèn)證和用戶授權(quán)（Authorization）搞混了。用戶授權(quán)指的是規(guī)定并允許用戶使用自己的權(quán)限，例如發(fā)布帖子、管理站點(diǎn)等。
首先，服務(wù)器應(yīng)用（下面簡稱“應(yīng)用”）讓用戶通過Web表單將自己的用戶名和密碼發(fā)送到服務(wù)器的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協(xié)議），從而避免敏感信息被嗅探。
接下來，應(yīng)用和數(shù)據(jù)庫核對用戶名和密碼。
核對用戶名和密碼成功后，應(yīng)用將用戶的id（圖中的user_id）作為JWT Payload的一個屬性，將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個JWT。這里的JWT就是一個形同lll.zzz.xxx的字符串。
應(yīng)用將JWT字符串作為該請求Cookie的一部分返回給用戶。注意，在這里必須使用HttpOnly屬性來防止Cookie被JavaScript讀取，從而避免跨站腳本攻擊（XSS攻擊）。
在Cookie失效或者被刪除前，用戶每次訪問應(yīng)用，應(yīng)用都會接受到含有jwt的Cookie。從而應(yīng)用就可以將JWT從請求中提取出來。
應(yīng)用通過一系列任務(wù)檢查JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
應(yīng)用在確認(rèn)JWT有效之后，JWT進(jìn)行Base64解碼（可能在上一步中已經(jīng)完成），然后在Payload中讀取用戶的id值，也就是user_id屬性。這里用戶的id為1025。
應(yīng)用從數(shù)據(jù)庫取到id為1025的用戶的信息，加載到內(nèi)存中，進(jìn)行ORM之類的一系列底層邏輯初始化。
應(yīng)用根據(jù)用戶請求進(jìn)行響應(yīng)。
所謂用戶認(rèn)證（Authentication），就是讓用戶登錄，并且在接下來的一段時間內(nèi)讓用戶訪問網(wǎng)站時可以使用其賬戶，而不需要再次登錄的機(jī)制。
小知識：可別把用戶認(rèn)證和用戶授權(quán)（Authorization）搞混了。用戶授權(quán)指的是規(guī)定并允許用戶使用自己的權(quán)限，例如發(fā)布帖子、管理站點(diǎn)等。
首先，服務(wù)器應(yīng)用（下面簡稱“應(yīng)用”）讓用戶通過Web表單將自己的用戶名和密碼發(fā)送到服務(wù)器的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協(xié)議），從而避免敏感信息被嗅探。
接下來，應(yīng)用和數(shù)據(jù)庫核對用戶名和密碼。
核對用戶名和密碼成功后，應(yīng)用將用戶的id（圖中的user_id）作為JWT Payload的一個屬性，將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個JWT。這里的JWT就是一個形同lll.zzz.xxx的字符串。
應(yīng)用將JWT字符串作為該請求Cookie的一部分返回給用戶。注意，在這里必須使用HttpOnly屬性來防止Cookie被JavaScript讀取，從而避免跨站腳本攻擊（XSS攻擊）。
在Cookie失效或者被刪除前，用戶每次訪問應(yīng)用，應(yīng)用都會接受到含有jwt的Cookie。從而應(yīng)用就可以將JWT從請求中提取出來。
應(yīng)用通過一系列任務(wù)檢查JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
應(yīng)用在確認(rèn)JWT有效之后，JWT進(jìn)行Base64解碼（可能在上一步中已經(jīng)完成），然后在Payload中讀取用戶的id值，也就是user_id屬性。這里用戶的id為1025。
應(yīng)用從數(shù)據(jù)庫取到id為1025的用戶的信息，加載到內(nèi)存中，進(jìn)行ORM之類的一系列底層邏輯初始化。
應(yīng)用根據(jù)用戶請求進(jìn)行響應(yīng)。
和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在于要占用大量服務(wù)器內(nèi)存，對于較大型應(yīng)用而言可能還要保存許多的狀態(tài)。一般而言，大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫和一系列緩存機(jī)制來實(shí)現(xiàn)Session的存儲。
而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力。除了用戶id之外，還可以存儲其他的和用戶相關(guān)的信息，例如該用戶是否是管理員、用戶所在的分桶（見[《你所應(yīng)該知道的A/B測試基礎(chǔ)》一文]( /2015/08/27/introduction-to-ab-testing/）等。
雖說JWT方式讓服務(wù)器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤I/O而言或許是半斤八兩。具體是否采用，需要在不同場景下用數(shù)據(jù)說話。
Session方式存儲用戶id的最大弊病在于要占用大量服務(wù)器內(nèi)存，對于較大型應(yīng)用而言可能還要保存許多的狀態(tài)。一般而言，大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫和一系列緩存機(jī)制來實(shí)現(xiàn)Session的存儲。
而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力。除了用戶id之外，還可以存儲其他的和用戶相關(guān)的信息，例如該用戶是否是管理員、用戶所在的分桶（見[《你所應(yīng)該知道的A/B測試基礎(chǔ)》一文]( /2015/08/27/introduction-to-ab-testing/）等。
雖說JWT方式讓服務(wù)器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤I/O而言或許是半斤八兩。具體是否采用，需要在不同場景下用數(shù)據(jù)說話。
單點(diǎn)登錄
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一臺服務(wù)器上。對于有多個子域名的站點(diǎn)，每個子域名至少會對應(yīng)一臺不同的服務(wù)器，例如：
www.taobao.com nv.taobao.com nz.taobao.com login.taobao.com
所以如果要實(shí)現(xiàn)在login.taobao.com登錄后，在其他的子域名下依然可以取到Session，這要求我們在多臺服務(wù)器上同步Session。
使用JWT的方式則沒有這個問題的存在，因?yàn)橛脩舻臓顟B(tài)已經(jīng)被傳送到了客戶端。因此，我們只需要將含有JWT的Cookie的domain設(shè)置為頂級域名即可，例如
Set-Cookie:?jwt=lll.zzz.xxx;?HttpOnly;?max-age=980000;?domain=.taobao.com
注意domain必須設(shè)置為一個點(diǎn)加頂級域名，即.taobao.com。這樣，taobao.com和*.taobao.com就都可以接受到這個Cookie，并獲取JWT了。
你好，來交個朋友 ~
往期推薦
END
若覺得文章對你有幫助，隨手轉(zhuǎn)發(fā)分享，也是我們繼續(xù)更新的動力。
長按二維碼，掃掃關(guān)注哦
?「C語言中文網(wǎng)」官方公眾號，關(guān)注手機(jī)閱讀教程??
學(xué)習(xí)資料包括：?Java，算法，數(shù)據(jù)庫，Linux，簡歷，運(yùn)維?等編程分類，在不斷更新中哦
點(diǎn)擊“閱讀原文”，馬上免費(fèi)領(lǐng)??！
??????
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一臺服務(wù)器上。對于有多個子域名的站點(diǎn)，每個子域名至少會對應(yīng)一臺不同的服務(wù)器，例如：
www.taobao.com nv.taobao.com nz.taobao.com login.taobao.com
所以如果要實(shí)現(xiàn)在login.taobao.com登錄后，在其他的子域名下依然可以取到Session，這要求我們在多臺服務(wù)器上同步Session。
使用JWT的方式則沒有這個問題的存在，因?yàn)橛脩舻臓顟B(tài)已經(jīng)被傳送到了客戶端。因此，我們只需要將含有JWT的Cookie的domain設(shè)置為頂級域名即可，例如
Set-Cookie:?jwt=lll.zzz.xxx;?HttpOnly;?max-age=980000;?domain=.taobao.com
注意domain必須設(shè)置為一個點(diǎn)加頂級域名，即.taobao.com。這樣，taobao.com和*.taobao.com就都可以接受到這個Cookie，并獲取JWT了。
你好，來交個朋友 ~
往期推薦
END
若覺得文章對你有幫助，隨手轉(zhuǎn)發(fā)分享，也是我們繼續(xù)更新的動力。
長按二維碼，掃掃關(guān)注哦
?「C語言中文網(wǎng)」官方公眾號，關(guān)注手機(jī)閱讀教程??