<noframes id="5hjpd"><progress id="5hjpd"><form id="5hjpd"></form></progress>

    <noframes id="5hjpd">

    <span id="5hjpd"><progress id="5hjpd"><progress id="5hjpd"></progress></progress></span>
      <noframes id="5hjpd">
      <ins id="5hjpd"><sub id="5hjpd"><rp id="5hjpd"></rp></sub></ins>
      <del id="5hjpd"><big id="5hjpd"></big></del>
      <track id="5hjpd"></track>

      前后端分離之JWT用戶認證

      導語   在前后端分離開發時為什么需要用戶認證呢?原因是由于HTTP協定是不儲存狀態的(stateless),這意味著當我們透過帳號密碼驗證一個使用者時,當下一個request請求時它就把剛剛的資料忘了。于是我們的程序就不知

        在前后端分離開發時為什么需要用戶認證呢?原因是由于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 了,它可能長這個樣子,長度貌似和你的加密算法和私鑰有關系。

        其實到這一步可能就有人會想了,HTTP 請求總會帶上 token,這樣這個 token 傳來傳去占用不必要的帶寬啊。如果你這么想了,那你可以去了解下 HTTP2,HTTP2 對頭部進行了壓縮,相信也解決了這個問題。

        簽名的目的

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

        信息暴露

        在這里大家一定會問一個問題:Base64是一種編碼,是可逆的,那么我的信息不就被暴露了嗎?

        是的。所以,在JWT中,不應該在負載里面加入任何敏感的數據。在上面的例子中,我們傳輸的是用戶的User ID。這個值實際上不是什么敏感內容,一般情況下被知道也是安全的。但是像密碼這樣的內容就不能被放在JWT中了。如果將用戶的密碼放在了JWT中,那么懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

        因此JWT適合用于向Web應用傳遞一些非敏感信息。JWT還經常用于設計用戶認證和授權系統,甚至實現Web應用的單點登錄。

        JWT 使用

      \

        首先,前端通過Web表單將自己的用戶名和密碼發送到后端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸(https協議),從而避免敏感信息被嗅探。

        后端核對用戶名和密碼成功后,將用戶的id等其他信息作為JWT Payload(負載),將其與頭部分別進行Base64編碼拼接后簽名,形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字符串。

        后端將JWT字符串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在localStorage或sessionStorage上,退出登錄時前端刪除保存的JWT即可。

        前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)

        后端檢查是否存在,如存在驗證JWT的有效性。例如,檢查簽名是否正確;檢查Token是否過期;檢查Token的接收方是否是自己(可選)。

        驗證通過后后端使用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://www.randomwithlife.com/ true 前后端分離之JWT用戶認證 http://www.randomwithlife.com/show-10-1113-1.html report <?php echo strlen($content) / 2; ?>   在前后端分離開發時為什么需要用戶認證呢?原因是由于HTTP協定是不儲存狀態的(stateless),這意味著當我們透過帳號密碼驗證一個使用者時,當下一個request請求時它就把剛剛的資料忘了。于是我們的程序就不知
      TAG:前后端分離 JWT
      本站歡迎任何形式的轉載,但請務必注明出處,尊重他人勞動成果
      轉載請注明: 文章轉載自:愛思資源網 http://www.randomwithlife.com/show-10-1113-1.html

      [前端插件推薦] Plugin

      1 2 3 4
      • jQuery實現逐字逐句顯示插件l-by-l.min.js
      • jQuery帶方向感知的鼠標滑過圖片邊框特效插件
      • jQuery HotKeys監聽鍵盤按下事件keydown插件
      • 響應式無限輪播jQuery旋轉木馬插件
      響應式無限輪播jQuery旋轉木馬插件
      web前端開發
      愛思資源網 Copyright 2012-2014 www.randomwithlife.com All rights reserved.(晉ICP備13001436號-1)
      欧美精品久久久久久久自慰

      <noframes id="5hjpd"><progress id="5hjpd"><form id="5hjpd"></form></progress>

        <noframes id="5hjpd">

        <span id="5hjpd"><progress id="5hjpd"><progress id="5hjpd"></progress></progress></span>
          <noframes id="5hjpd">
          <ins id="5hjpd"><sub id="5hjpd"><rp id="5hjpd"></rp></sub></ins>
          <del id="5hjpd"><big id="5hjpd"></big></del>
          <track id="5hjpd"></track>