上次在《JSON Web Token - 在Web應(yīng)用間安全地傳遞信息》中我提到了JSON Web Token可以用來(lái)設(shè)計(jì)單點(diǎn)登錄系統(tǒng)。我嘗試用八幅漫畫先讓大家理解如何設(shè)計(jì)正常的用戶認(rèn)證系統(tǒng),然后再延伸到單點(diǎn)登錄系統(tǒng)。 如果還沒有閱讀《JSON Web Token - 在Web應(yīng)用間安全地傳遞信息》,我強(qiáng)烈建議你花十分鐘閱讀它,理解JWT的生成過程和原理。 用戶認(rèn)證八步走所謂用戶認(rèn)證(Authentication),就是讓用戶登錄,并且在接下來(lái)的一段時(shí)間內(nèi)讓用戶訪問網(wǎng)站時(shí)可以使用其賬戶,而不需要再次登錄的機(jī)制。
首先,服務(wù)器應(yīng)用(下面簡(jiǎn)稱“應(yīng)用”)讓用戶通過Web表單將自己的用戶名和密碼發(fā)送到服務(wù)器的接口。這一過程一般是一個(gè)HTTP POST請(qǐng)求。建議的方式是通過SSL加密的傳輸(https協(xié)議),從而避免敏感信息被嗅探。 ![]() 接下來(lái),應(yīng)用和數(shù)據(jù)庫(kù)核對(duì)用戶名和密碼。 ![]() 核對(duì)用戶名和密碼成功后,應(yīng)用將用戶的 ![]() 應(yīng)用將JWT字符串作為該請(qǐng)求Cookie的一部分返回給用戶。注意,在這里必須使用 ![]() 在Cookie失效或者被刪除前,用戶每次訪問應(yīng)用,應(yīng)用都會(huì)接受到含有 ![]() 應(yīng)用通過一系列任務(wù)檢查JWT的有效性。例如,檢查簽名是否正確;檢查Token是否過期;檢查Token的接收方是否是自己(可選)。 ![]() 應(yīng)用在確認(rèn)JWT有效之后,JWT進(jìn)行Base64解碼(可能在上一步中已經(jīng)完成),然后在Payload中讀取用戶的id值,也就是 ![]() 應(yīng)用從數(shù)據(jù)庫(kù)取到 ![]() 應(yīng)用根據(jù)用戶請(qǐng)求進(jìn)行響應(yīng)。 ![]() 和Session方式存儲(chǔ)id的差異Session方式存儲(chǔ)用戶id的最大弊病在于要占用大量服務(wù)器內(nèi)存,對(duì)于較大型應(yīng)用而言可能還要保存許多的狀態(tài)。一般而言,大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫(kù)和一系列緩存機(jī)制來(lái)實(shí)現(xiàn)Session的存儲(chǔ)。 而JWT方式將用戶狀態(tài)分散到了客戶端中,可以明顯減輕服務(wù)端的內(nèi)存壓力。除了用戶id之外,還可以存儲(chǔ)其他的和用戶相關(guān)的信息,例如該用戶是否是管理員、用戶所在的分桶(見[《你所應(yīng)該知道的A/B測(cè)試基礎(chǔ)》一文](/2015/08/27/introduction-to-ab-testing/)等。 雖說JWT方式讓服務(wù)器有一些計(jì)算壓力(例如加密、編碼和解碼),但是這些壓力相比磁盤I/O而言或許是半斤八兩。具體是否采用,需要在不同場(chǎng)景下用數(shù)據(jù)說話。 單點(diǎn)登錄Session方式來(lái)存儲(chǔ)用戶id,一開始用戶的Session只會(huì)存儲(chǔ)在一臺(tái)服務(wù)器上。對(duì)于有多個(gè)子域名的站點(diǎn),每個(gè)子域名至少會(huì)對(duì)應(yīng)一臺(tái)不同的服務(wù)器,例如:
所以如果要實(shí)現(xiàn)在 使用JWT的方式則沒有這個(gè)問題的存在,因?yàn)橛脩舻臓顟B(tài)已經(jīng)被傳送到了客戶端。因此,我們只需要將含有JWT的Cookie的
注意 對(duì)于JWT的兩篇文章有相關(guān)問題的同學(xué)請(qǐng)直接在下面的評(píng)論區(qū)與我討論(請(qǐng)勿郵件討論)。如果你感興趣,你可以在下方訂閱我的半月刊,我將給你推送更多精彩的內(nèi)容;) |
|