先後端分離之JWT用戶認證

在先後端分離開發時爲何須要用戶認證呢？緣由是因爲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。

Json Web Token（JWT）

JWT 是一個開放標準(RFC 7519)，它定義了一種用於簡潔，自包含的用於通訊雙方之間以 JSON 對象的形式安全傳遞信息的方法。JWT 可使用 HMAC 算法或者是 RSA 的公鑰密鑰對進行簽名。它具有兩個特色：

• 簡潔(Compact)

  能夠經過URL, POST 參數或者在 HTTP header 發送，由於數據量小，傳輸速度快

• 自包含(Self-contained)

  負載中包含了全部用戶所須要的信息，避免了屢次查詢數據庫

JWT 組成

• Header 頭部

頭部包含了兩部分，token 類型和採用的加密算法

{
  "alg": "HS256", "typ": "JWT" } 

它會使用 Base64 編碼組成 JWT 結構的第一部分,若是你使用Node.js，能夠用Node.js的包base64url來獲得這個字符串。

Base64是一種編碼，也就是說，它是能夠被翻譯回原來的樣子來的。它並非一種加密過程。

• Payload 負載

這部分就是咱們存放信息的地方了，你能夠把用戶 ID 等信息放在這裏，JWT 規範裏面對這部分有進行了比較詳細的介紹，經常使用的由 iss（簽發者），exp（過時時間），sub（面向的用戶），aud（接收方），iat（簽發時間）。

{
    "iss": "lion1ou JWT", "iat": 1441593502, "exp": 1441594722, "aud": "www.example.com", "sub": "lion1ou@163.com" } 

一樣的，它會使用 Base64 編碼組成 JWT 結構的第二部分

• Signature 簽名

前面兩部分都是使用 Base64 進行編碼的，即前端能夠解開知道里面的信息。Signature 須要使用編碼後的 header 和 payload 以及咱們提供的一個密鑰，而後使用 header 中指定的簽名算法（HS256）進行簽名。簽名的做用是保證 JWT 沒有被篡改過。

三個部分經過.鏈接在一塊兒就是咱們的 JWT 了，它可能長這個樣子，長度貌似和你的加密算法和私鑰有關係。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

其實到這一步可能就有人會想了，HTTP 請求總會帶上 token，這樣這個 token 傳來傳去佔用沒必要要的帶寬啊。若是你這麼想了，那你能夠去了解下 HTTP2，HTTP2 對頭部進行了壓縮，相信也解決了這個問題。

• 簽名的目的

最後一步簽名的過程，其實是對頭部以及負載內容進行簽名，防止內容被竄改。若是有人對頭部以及負載的內容解碼以後進行修改，再進行編碼，最後加上以前的簽名組合造成新的JWT的話，那麼服務器端會判斷出新的頭部和負載造成的簽名和JWT附帶上的簽名是不同的。若是要對新的頭部和負載進行簽名，在不知道服務器加密時用的密鑰的話，得出來的簽名也是不同的。

• 信息暴露

在這裏你們必定會問一個問題：Base64是一種編碼，是可逆的，那麼個人信息不就被暴露了嗎？

是的。因此，在JWT中，不該該在負載裏面加入任何敏感的數據。在上面的例子中，咱們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容，通常狀況下被知道也是安全的。可是像密碼這樣的內容就不能被放在JWT中了。若是將用戶的密碼放在了JWT中，那麼懷有惡意的第三方經過Base64解碼就能很快地知道你的密碼了。

所以JWT適合用於向Web應用傳遞一些非敏感信息。JWT還常常用於設計用戶認證和受權系統，甚至實現Web應用的單點登陸。

JWT 使用

1. 首先，前端經過Web表單將本身的用戶名和密碼發送到後端的接口。這一過程通常是一個HTTP POST請求。建議的方式是經過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。
2. 後端覈對用戶名和密碼成功後，將用戶的id等其餘信息做爲JWT Payload（負載），將其與頭部分別進行Base64編碼拼接後簽名，造成一個JWT。造成的JWT就是一個形同lll.zzz.xxx的字符串。
3. 後端將JWT字符串做爲登陸成功的返回結果返回給前端。前端能夠將返回的結果保存在localStorage或sessionStorage上，退出登陸時前端刪除保存的JWT便可。
4. 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
5. 後端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過時；檢查Token的接收方是不是本身（可選）。
6. 驗證經過後後端使用JWT中包含的用戶信息進行其餘邏輯操做，返回相應結果。

和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的方式則沒有這個問題的存在，由於用戶的狀態已經被傳送到了客戶端。

總結

JWT的主要做用在於

（一）可附帶用戶信息，後端直接經過JWT獲取相關信息。

（二）使用本地保存，經過HTTP Header中的Authorization位提交驗證。但其實關於JWT存放到哪裏一直有不少討論，有人說存放到本地存儲，有人說存 cookie。我的偏向於放在本地存儲，若是你有什麼意見和見解歡迎提出。

 

轉載自http://lion1ou.win/2017/01/18/

(end)