【第1328期】八幅漫畫理解使用JSON Web Token設計單點登錄系統

前端早讀課2018-07-12 05:36:37

前言

這周在活動抽獎羣裏有人提到JWT,那今天來看看這是啥?今日早讀文章由@子回授權分享。

在很多年前有分享過【第348期】JSON Web Token - 在Web應用間安全地傳遞信息,可以用來理解下JWT的生成過程和原理。

正文從這開始~

用户認證八步走

所謂用户認證(Authentication),就是讓用户登錄,並且在接下來的一段時間內讓用户訪問網站時可以使用其賬户,而不需要再次登錄的機制。

小知識:可別把用户認證和用户授權(Authorization)搞混了。用户授權指的是規定並允許用户使用自己的權限,例如發佈帖子、管理站點等。

首先,服務器應用(下面簡稱“應用”)讓用户通過Web表單將自己的用户名和密碼發送到服務器的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸(https協議),從而避免敏感信息被嗅探。

接下來,應用和數據庫核對用户名和密碼。

核對用户名和密碼成功後,應用將用户的id(圖中的user_id)作為JWT Payload的一個屬性,將其與頭部分別進行Base64編碼拼接後簽名,形成一個JWT。這裏的JWT就是一個形同lll.zzz.xxx的字符串。

應用將JWT字符串作為該請求Cookie的一部分返回給用户。注意,在這裏必須使用HttpOnly屬性來防止Cookie被JavaScript讀取,從而避免跨站腳本攻擊(XSS攻擊)。

在Cookie失效或者被刪除前,用户每次訪問應用,應用都會接受到含有jwt的Cookie。從而應用就可以將JWT從請求中提取出來。

應用通過一系列任務檢查JWT的有效性。例如,檢查簽名是否正確;檢查Token是否過期;檢查Token的接收方是否是自己(可選)。

應用在確認JWT有效之後,JWT進行Base64解碼(可能在上一步中已經完成),然後在Payload中讀取用户的id值,也就是user_id屬性。這裏用户的id為1025。


應用從數據庫取到id為1025的用户的信息,加載到內存中,進行ORM之類的一系列底層邏輯初始化。

應用根據用户請求進行響應。

和Session方式存儲id的差異

Session方式存儲用户id的最大弊病在於要佔用大量服務器內存,對於較大型應用而言可能還要保存許多的狀態。一般而言,大型應用還需要藉助一些KV數據庫和一系列緩存機制來實現Session的存儲。

而JWT方式將用户狀態分散到了客户端中,可以明顯減輕服務端的內存壓力。除了用户id之外,還可以存儲其他的和用户相關的信息,例如該用户是否是管理員、用户所在的分桶(見[《你所應該知道的A/B測試基礎》一文](/2015/08/27/introduction-to-ab-testing/)等。

雖説JWT方式讓服務器有一些計算壓力(例如加密、編碼和解碼),但是這些壓力相比磁盤I/O而言或許是半斤八兩。具體是否採用,需要在不同場景下用數據説話。

單點登錄

Session方式來存儲用户id,一開始用户的Session只會存儲在一台服務器上。對於有多個子域名的站點,每個子域名至少會對應一台不同的服務器,例如:

  • www.taobao.com

  • nv.taobao.com

  • nz.taobao.com

  • login.taobao.com


所以如果要實現在login.taobao.com登錄後,在其他的子域名下依然可以取到Session,這要求我們在多台服務器上同步Session。


使用JWT的方式則沒有這個問題的存在,因為用户的狀態已經被傳送到了客户端。因此,我們只需要將含有JWT的Cookie的domain設置為頂級域名即可,例如

Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.com

注意domain必須設置為一個點加頂級域名,即.taobao.com。這樣,taobao.com和*.taobao.com就都可以接受到這個Cookie,並獲取JWT了。

關於本文
作者:@子回
原文:
http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/

最後,為你推薦


【第1325期】以開發的視角做設計


【第1323期】揭開JS無埋點技術的神祕面紗


閲讀原文

TAGS:用户應用用户認證可以