在前後端分離開發時爲什麼需要用戶認證呢?原因是由於HTTP協定是不儲存狀態的(stateless),這意味着當我們透過帳號密碼驗證一個使用者時,當下一個request請求時它就把剛剛的資料忘了。於是我們的程序就不知道誰是誰,就要再驗證一次。所以爲了保證系統安全,我們就需要驗證用戶否處於登錄狀態。
傳統方式
前後端分離通過Restful API進行數據交互時,如何驗證用戶的登錄信息及權限。在原來的項目中,使用的是最傳統也是最簡單的方式,前端登錄,後端根據用戶信息生成一個token
,並保存這個 token
和對應的用戶id到數據庫或Session中,接着把 token
傳給用戶,存入瀏覽器 cookie,之後瀏覽器請求帶上這個cookie,後端根據這個cookie值來查詢用戶,驗證是否過期。
但這樣做問題就很多,如果我們的頁面出現了 XSS 漏洞,由於 cookie 可以被 JavaScript 讀取,XSS 漏洞會導致用戶 token 泄露,而作爲後端識別用戶的標識,cookie 的泄露意味着用戶信息不再安全。儘管我們通過轉義輸出內容,使用 CDN 等可以儘量避免 XSS 注入,但誰也不能保證在大型的項目中不會出現這個問題。
在設置 cookie 的時候,其實你還可以設置 httpOnly 以及 secure 項。設置 httpOnly 後 cookie 將不能被 JS 讀取,瀏覽器會自動的把它加在請求的 header 當中,設置 secure 的話,cookie 就只允許通過 HTTPS 傳輸。secure 選項可以過濾掉一些使用 HTTP 協議的 XSS 注入,但並不能完全阻止。
httpOnly 選項使得 JS 不能讀取到 cookie,那麼 XSS 注入的問題也基本不用擔心了。但設置 httpOnly 就帶來了另一個問題,就是很容易的被 XSRF,即跨站請求僞造。當你瀏覽器開着這個頁面的時候,另一個頁面可以很容易的跨站請求這個頁面的內容。因爲 cookie 默認被髮了出去。
另外,如果將驗證信息保存在數據庫中,後端每次都需要根據token
查出用戶id
,這就增加了數據庫的查詢和存儲開銷。若把驗證信息保存在session中,有加大了服務器端的存儲壓力。那我們可不可以不要服務器去查詢呢?如果我們生成token
遵循一定的規律,比如我們使用對稱加密算法來加密用戶id
形成token
,那麼服務端以後其實只要解密該token
就可以知道用戶的id
是什麼了。不過呢,我只是舉個例子而已,要是真這麼做,只要你的對稱加密算法泄露了,其他人可以通過這種加密方式進行僞造token
,那麼所有用戶信息都不再安全了。恩,那用非對稱加密算法來做呢,其實現在有個規範就是這樣做的,就是我們接下來要介紹的 JWT。
JWT簡介
JWT,全稱是Json Web Token, 是JSON風格輕量級的授權和身份認證規範,可實現無狀態、分佈式的Web應用授權;官網:https://jwt.io
GitHub上jwt的java客戶端:https://github.com/jwtk/jjwt
數據格式
JWT包含三部分數據:
-
Header:頭部,通常頭部有兩部分信息:
- 聲明類型,這裏是JWT
- 加密算法,自定義
我們會對頭部進行base64加密(可解密),得到第一部分數據
-
Payload:載荷,就是有效數據,一般包含下面信息:
- 用戶身份信息(注意,這裏因爲採用base64加密,可解密,因此不要存放敏感信息)
- 註冊聲明:如token的簽發時間,過期時間,簽發人等
這部分也會採用base64加密,得到第二部分數據
-
Signature:簽名,是整個數據的認證信息。一般根據前兩步的數據,再加上服務的的密鑰(secret)(不要泄漏,最好週期性更換),通過加密算法生成。用於驗證整個數據完整和可靠性
生成的數據格式:
可以看到分爲3段,每段就是上面的一部分數據
其實到這一步可能就有人會想了,HTTP 請求總會帶上 token,這樣這個 token 傳來傳去佔用不必要的帶寬啊。如果你這麼想了,那你可以去了解下 HTTP2,HTTP2 對頭部進行了壓縮,相信也解決了這個問題。
- 簽名的目的
最後一步簽名的過程,實際上是對頭部以及負載內容進行簽名,防止內容被竄改。如果有人對頭部以及負載的內容解碼之後進行修改,再進行編碼,最後加上之前的簽名組合形成新的JWT的話,那麼服務器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名,在不知道服務器加密時用的密鑰的話,得出來的簽名也是不一樣的。
- 信息暴露
在這裏大家一定會問一個問題:Base64是一種編碼,是可逆的,那麼我的信息不就被暴露了嗎?
是的。所以,在JWT中,不應該在負載裏面加入任何敏感的數據。在上面的例子中,我們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容,一般情況下被知道也是安全的。但是像密碼這樣的內容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中,那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
因此JWT適合用於向Web應用傳遞一些非敏感信息。JWT還經常用於設計用戶認證和授權系統,甚至實現Web應用的單點登錄。
JWT交互流程
流程圖:
步驟翻譯:
- 1、用戶登錄
- 2、服務的認證,通過後根據secret生成token
- 3、將生成的token返回給瀏覽器
- 4、用戶每次請求攜帶token
- 5、服務端利用公鑰解讀jwt簽名,判斷簽名有效後,從Payload中獲取用戶信息
- 6、處理請求,返回響應結果
因爲JWT簽發的token中已經包含了用戶的身份信息,並且每次請求都會攜帶,這樣服務的就無需保存用戶信息,甚至無需去數據庫查詢,完全符合了Rest的無狀態規範。
和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在於Session是存儲在服務器端的,所以需要佔用大量服務器內存,對於較大型應用而言可能還要保存許多的狀態。一般而言,大型應用還需要藉助一些KV數據庫和一系列緩存機制來實現Session的存儲。
而JWT方式將用戶狀態分散到了客戶端中,可以明顯減輕服務端的內存壓力。除了用戶id之外,還可以存儲其他的和用戶相關的信息,例如該用戶是否是管理員、用戶所在的分組等。雖說JWT方式讓服務器有一些計算壓力(例如加密、編碼和解碼),但是這些壓力相比磁盤存儲而言可能就不算什麼了。具體是否採用,需要在不同場景下用數據說話。
- 單點登錄
Session方式來存儲用戶id,一開始用戶的Session只會存儲在一臺服務器上。對於有多個子域名的站點,每個子域名至少會對應一臺不同的服務器,例如:www.taobao.com
,nv.taobao.com
,nz.taobao.com
,login.taobao.com
。所以如果要實現在login.taobao.com
登錄後,在其他的子域名下依然可以取到Session,這要求我們在多臺服務器上同步Session。使用JWT的方式則沒有這個問題的存在,因爲用戶的狀態已經被傳送到了客戶端。
非對稱加密
加密技術是對信息進行編碼和解碼的技術,編碼是把原來可讀信息(又稱明文)譯成代碼形式(又稱密文),其逆過程就是解碼(解密),加密技術的要點是加密算法,加密算法可以分爲三類:
- 對稱加密,如AES
- 基本原理:將明文分成N個組,然後使用密鑰對各個組進行加密,形成各自的密文,最後把所有的分組密文進行合併,形成最終的密文。
- 優勢:算法公開、計算量小、加密速度快、加密效率高
- 缺陷:雙方都使用同樣密鑰,安全性得不到保證
- 非對稱加密,如RSA
- 基本原理:同時生成兩把密鑰:私鑰和公鑰,私鑰隱祕保存,公鑰可以下發給信任客戶端
- 私鑰加密,持有私鑰或公鑰纔可以解密
- 公鑰加密,持有私鑰纔可解密
- 優點:安全,難以破解
- 缺點:算法比較耗時
- 基本原理:同時生成兩把密鑰:私鑰和公鑰,私鑰隱祕保存,公鑰可以下發給信任客戶端
- 不可逆加密,如MD5,SHA
- 基本原理:加密過程中不需要使用密鑰,輸入明文後由系統直接經過加密算法處理成密文,這種加密後的數據是無法被解密的,無法根據密文推算出明文。
RSA算法歷史:
1977年,三位數學家Rivest、Shamir 和 Adleman 設計了一種算法,可以實現非對稱加密。這種算法用他們三個人的名字縮寫:RSA
總結
JWT的主要作用在於:
- 可附帶用戶信息,後端直接通過JWT獲取相關信息。
- 使用本地保存,通過HTTP Header中的Authorization位提交驗證。
參考:http://lion1ou.win/2017/01/18/