|
上次在《JSON Web Token - 在Web應(yīng)用間安全地傳遞信息》中我提到了JSON Web Token可以用來設(shè)計單點登錄系統(tǒng)。我嘗試用八幅漫畫先讓大家理解如何設(shè)計正常的用戶認證系統(tǒng),然后再延伸到單點登錄系統(tǒng)。 如果還沒有閱讀《JSON Web Token - 在Web應(yīng)用間安全地傳遞信息》,我強烈建議你花十分鐘閱讀它,理解JWT的生成過程和原理。 用戶認證八步走所謂用戶認證(Authentication),就是讓用戶登錄,并且在接下來的一段時間內(nèi)讓用戶訪問網(wǎng)站時可以使用其賬戶,而不需要再次登錄的機制。
首先,服務(wù)器應(yīng)用(下面簡稱“應(yīng)用”)讓用戶通過Web表單將自己的用戶名和密碼發(fā)送到服務(wù)器的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸(https協(xié)議),從而避免敏感信息被嗅探。
接下來,應(yīng)用和數(shù)據(jù)庫核對用戶名和密碼。
核對用戶名和密碼成功后,應(yīng)用將用戶的
應(yīng)用將JWT字符串作為該請求Cookie的一部分返回給用戶。注意,在這里必須使用
在Cookie失效或者被刪除前,用戶每次訪問應(yīng)用,應(yīng)用都會接受到含有
應(yīng)用通過一系列任務(wù)檢查JWT的有效性。例如,檢查簽名是否正確;檢查Token是否過期;檢查Token的接收方是否是自己(可選)。
應(yīng)用在確認JWT有效之后,JWT進行Base64解碼(可能在上一步中已經(jīng)完成),然后在Payload中讀取用戶的id值,也就是
應(yīng)用從數(shù)據(jù)庫取到
應(yīng)用根據(jù)用戶請求進行響應(yīng)。
和Session方式存儲id的差異Session方式存儲用戶id的最大弊病在于要占用大量服務(wù)器內(nèi)存,對于較大型應(yīng)用而言可能還要保存許多的狀態(tài)。一般而言,大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫和一系列緩存機制來實現(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,一開始用戶的Session只會存儲在一臺服務(wù)器上。對于有多個子域名的站點,每個子域名至少會對應(yīng)一臺不同的服務(wù)器,例如:
所以如果要實現(xiàn)在 使用JWT的方式則沒有這個問題的存在,因為用戶的狀態(tài)已經(jīng)被傳送到了客戶端。因此,我們只需要將含有JWT的Cookie的
注意 對于JWT的兩篇文章有相關(guān)問題的同學(xué)請直接在下面的評論區(qū)與我討論(請勿郵件討論)。如果你感興趣,你可以在下方訂閱我的半月刊,我將給你推送更多精彩的內(nèi)容;) |
|
|