1. 程式人生 > >前後端分離之JWT使用者認證

前後端分離之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": "[email protected]"
}

同樣的,它會使用 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.comnv.taobao.comnz.taobao.comlogin.taobao.com。所以如果要實現在login.taobao.com登入後,在其他的子域名下依然可以取到Session,這要求我們在多臺伺服器上同步Session。使用JWT的方式則沒有這個問題的存在,因為使用者的狀態已經被傳送到了客戶端。

總結

JWT的主要作用在於(一)可附帶使用者資訊,後端直接通過JWT獲取相關資訊。(二)使用本地儲存,通過HTTP Header中的Authorization位提交驗證。但其實關於JWT存放到哪裡一直有很多討論,有人說存放到本地儲存,有人說存 cookie。個人偏向於放在本地儲存,如果你有什麼意見和看法歡迎提出。

參考:1 2 3

轉載請標註原文地址

(end)

相關推薦

[django]前後分離JWT使用者認證

在前後端分離開發時為什麼需要使用者認證呢?原因是由於HTTP協定是不儲存狀態的(stateless),這意味著當我們透過帳號密碼驗證一個使用者時,當下一個request請求時它就把剛剛的資料忘了。於是我們的程式就不知道誰是誰,就要再驗證一次。所以為了保證系統安全,我們就需要驗證使用者否處於登入狀態。 傳統方

前後分離JWT使用者認證

在前後端分離開發時為什麼需要使用者認證呢?原因是由於HTTP協定是不儲存狀態的(stateless),這意味著當我們透過帳號密碼驗證一個使用者時,當下一個request請求時它就把剛剛的資料忘了。於是我們的程式就不知道誰是誰,就要再驗證一次。所以為了保證系統安全,我們就需要驗證使用者否處於登入狀態。傳統方式前

前後分離SpringBoot專案Token認證

寫在開始 有人說,愛上一座城,是因為城中住著某個喜歡的人。其實不然,愛上一座城,也許是為城裡的一道生動風景,為一段青梅往事,為一座熟悉老宅。或許,僅僅為的只是這座城。就像愛上一個人,有時候不需要任何理由,沒有前因,無關風月,只是愛了。 —林徽因   前段時間,大體

前後分離mockjs基本介紹

body pos mock 響應 func 正則 str 整數 fun 安裝與使用 # 安裝 npm install mockjs #使用 Mock var Mock = require(‘mockjs‘) var data = Mock.mock({ // 屬性

前後分離VueJS前端

程式碼:https://github.com/jimolonely/vue-jwt-demo 前言 前端用什麼框架都可以,這裡選擇小巧的vuejs。 要實現的功能很簡單:  1、登入功能,成功將伺服器返回的token存在本地  2、使用帶token的header訪問伺服器

前後分離Java後

前後端分離的思想由來已久,不妨嘗試一下,從上手開始,先把程式碼寫出來再究細節。 程式碼下載:https://github.com/jimolonely/AuthServer 前言 以前服務端為什麼能識別使用者呢?對,是session,每個session都存在服務端,瀏覽器每次請求都帶著ses

shiro,基於springboot,基於前後分離,從登入認證到鑑權,從入門到放棄

這個demo是基於springboot專案的。 名詞介紹: ShiroShiro 主要分為 安全認證 和 介面授權 兩個部分,其中的核心元件為 Subject、 SecurityManager、 Realms,公共部分 Shiro 都已經為我們封裝好了,我們只需要按照一定的規則去編寫響應的程式碼即可…

前後分離介面定義滯後帶來的問題

   前言:   目前正參與我司一個後臺管理型專案,我司採取的是前後端分離開發,後端採用dubbo框架提供介面,前端整合egg.js和dubbo.js;各司其職,我和一道友專門負責前端伺服器整個模組,伺服器搭建探索過程費了點時間(也不太多),然後就前端頁面的排期,給我的模組排了

Django前後分離域名配置

編輯檔案  sudo vim /etc/hosts 將兩個域名新增到檔案中 127.0.0.1 api.xxxx.site 127.0.0.1 www.xxxx2.site  前端xxxx/js目錄中,建立host.js檔案用以為前端儲存後端域名 var h

基於小程式開發的前後分離登入狀態

公司接了一個小程式的活。本來後臺想用的是session儲存登入狀態。後來發現登入存進去的sessionId和取時候的sessionId不一樣,匯入無法取到登入狀態,百度了一下才知道,原來是小程式端不支援儲存cookie,後來想到了在微信登入授權後,把openId加密(token),當做key,ope

前後分離_後_分類導航功能_就是_三級分類,表是無限極的設計

需求: 1. 資料庫 設計原則:無限極分類 2, 介面 3,實現 3.1 pojo 3.2, dao 我用的是mybatis 3.3,service 用的example多條件查詢 public List<Categ

前後分離SEO優化--------以vue為例

   前言----SEO是由英文Search Engine Optimization縮寫而來, 中文意譯為“搜尋引擎優化”。SEO是指通過對網站進行站內優化和修復(網站Web結構調整、網站內容建設、網站

springboot前後分離跨域

springmvc有多種處理跨域的方法,介紹最簡單的一種: @Configuration public class WebMvcConfig extends WebMvcConfigurerAdapter { @Override public void addCors

前後分離vue2.0+webpack2 實戰專案 -- html模板拼接

對於前後端分離,如何把一個頁面的公共部分比如head, header, footer, content等組合成一個完整的html 是一個值得考慮的地方。對於php,我們可以利用include載入其他頁面,像yii框架,可以利用render將輸出的內容嵌入到父模板,從而形成一個

前後分離Vue(三)爬過得那些坑

爬過得那些坑前言:在整個Vue的過程中,遇到了不少坑。查詢不同的資料,把這些坑給填了,記錄下這些坑,以及解決辦法。一、Http請求的那些坑1.不支援http請求表現為:程式啟動正常,點選按妞不跳轉,後臺無響應,瀏覽器調試出現Uncaught TypeError: Cannot

前後分離Springboot後

這是上一篇部落格前後端分離之Java後端的重寫. 原始碼 前後端分離的後端主要解決的就2個問題 : 跨域訪問(CORS)和token校驗,下面快速說明. 1.專案環境 使用Intellij IDE. 專案結構: 2.跨域訪問 解決跨域很簡單,翻

前後分離session問題

背景目前正在開發的專案是前後端分離的專案,前端是react,後端springboot開發的微服務,在除錯登入的時候發現,登入成功後把所需的資訊都放到session中並存到redis裡,但當用戶從session中取資訊的時候發現始終取不到,每次跨域請求時ajax傳送的都是新的s

前後分離模式下JWT使用者認證及其在DRF中的應用

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

從壹開始前後分離【 .NET Core2.0 +Vue2.0 】框架五 || Swagger的使用 3.3 JWT許可權驗證【修改】

重大更新: 兩個是上下銜接的,主要是解決本文中,過期時間無效的問題。 群友反饋: 群裡有小夥伴反饋,在Swagger使用的時候報錯,無法看到列表,這裡我說下如何除錯和主要問題: 1、如果遇到問題,這樣的: 請在瀏覽器 =》 F12 ==》 console 控制檯 ==》點選錯誤資

laravel使用者認證 JWT-Auth 前後分離

本章主要介紹前後端徹底分離時,如何使用laravel實現API認證,(laravel5.5) 首先,你得有一個laravel專案,拉取新框架命令:composer create-project laravel/laravel 專案名稱 --prefer-dist “5.5.*” Be