Token ,Cookie、Session 三者區別

Full Stack Developme發表於2020-11-09

轉載自:cnblogs.com/JamesWang1993/p/8593494.html

敘述

在做介面測試時,經常會碰到請求引數為token的型別,但是可能大部分測試人員對token,cookie,session的區別還是一知半解。

Cookie

cookie 是一個非常具體的東西,指的就是瀏覽器裡面能永久儲存的一種資料,僅僅是瀏覽器實現的一種資料儲存功能。

cookie由伺服器生成,傳送給瀏覽器,瀏覽器把cookie以kv形式儲存到某個目錄下的文字檔案內,下一次請求同一網站時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的,所以瀏覽器加入了一些限制確保cookie不會被惡意使用,同時不會佔據太多磁碟空間,所以每個域的cookie數量是有限的。

Session

session 從字面上講,就是會話。這個就類似於你和一個人交談,你怎麼知道當前和你交談的是張三而不是李四呢?對方肯定有某種特徵(長相等)表明他就是張三。

session 也是類似的道理,伺服器要知道當前發請求給自己的是誰。為了做這種區分,伺服器就要給每個客戶端分配不同的“身份標識”,然後客戶端每次向伺服器發請求的時候,都帶上這個“身份標識”,伺服器就知道這個請求來自於誰了。至於客戶端怎麼儲存這個“身份標識”,可以有很多種方式,對於瀏覽器客戶端,大家都預設採用 cookie 的方式。

伺服器使用session把使用者的資訊臨時儲存在了伺服器上,使用者離開網站後session會被銷燬。這種使用者資訊儲存方式相對cookie來說更安全,可是session有一個缺陷:如果web伺服器做了負載均衡,那麼下一個操作請求到了另一臺伺服器的時候session會丟失。

Token

Token的引入:Token是在客戶端頻繁向服務端請求資料,服務端頻繁的去資料庫查詢使用者名稱和密碼並進行對比,判斷使用者名稱和密碼正確與否,並作出相應提示,在這樣的背景下,Token便應運而生。

Token的定義:Token是服務端生成的一串字串,以作客戶端進行請求的一個令牌,當第一次登入後,伺服器生成一個Token便將此Token返回給客戶端,以後客戶端只需帶上這個Token前來請求資料即可,無需再次帶上使用者名稱和密碼。最簡單的token組成:uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名,由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進位制字串,可以防止惡意第三方拼接token請求伺服器)。

使用Token的目的:Token的目的是為了減輕伺服器的壓力,減少頻繁的查詢資料庫,使伺服器更加健壯。

 

傳統身份驗證

HTTP 是一種沒有狀態的協議,也就是它並不知道是誰是訪問應用。這裡我們把使用者看成是客戶端,客戶端使用使用者名稱還有密碼通過了身份驗證,不過下回這個客戶端再傳送請求時候,還得再驗證一下。

解決的方法就是,當使用者請求登入的時候,如果沒有問題,我們在服務端生成一條記錄,這個記錄裡可以說明一下登入的使用者是誰,然後把這條記錄的 ID 號傳送給客戶端,客戶端收到以後把這個 ID 號儲存在 Cookie 裡,下次這個使用者再向服務端傳送請求的時候,可以帶著這個 Cookie ,這樣服務端會驗證一個這個 Cookie 裡的資訊,看看能不能在服務端這裡找到對應的記錄,如果可以,說明使用者已經通過了身份驗證,就把使用者請求的資料返回給客戶端。

上面說的就是 Session,我們需要在服務端儲存為登入的使用者生成的 Session ,這些 Session 可能會儲存在記憶體,磁碟,或者資料庫裡。我們可能需要在服務端定期的去清理過期的 Session 。

基於 Token 的身份驗證

使用基於 Token 的身份驗證方法,在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的:

  • 客戶端使用使用者名稱跟密碼請求登入

  • 服務端收到請求,去驗證使用者名稱與密碼

  • 驗證成功後,服務端會簽發一個 Token,再把這個 Token 傳送給客戶端

  • 客戶端收到 Token 以後可以把它儲存起來,比如放在 Cookie 裡或者 Local Storage 裡

  • 客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 Token

  • 服務端收到請求,然後去驗證客戶端請求裡面帶著的 Token,如果驗證成功,就向客戶端返回請求的資料

APP登入的時候傳送加密的使用者名稱和密碼到伺服器,伺服器驗證使用者名稱和密碼,如果成功,以某種方式比如隨機生成32位的字串作為token,儲存到伺服器中,並返回token到APP,以後APP請求時,凡是需要驗證的地方都要帶上該token,然後伺服器端驗證token,成功返回所需要的結果,失敗返回錯誤資訊,讓他重新登入。其中伺服器上token設定一個有效期,每次APP請求的時候都驗證token和有效期。

那麼我的問題來了:1.伺服器上的token儲存到資料庫中,每次查詢會不會很費時。如果不儲存到資料庫,應該儲存到哪裡呢。2.客戶端得到的token肯定要加密儲存的,傳送token的時候再解密。儲存到資料庫還是配置檔案呢?

token是個易失資料,丟了無非讓使用者重新登入一下,新浪微博動不動就讓我重新登入,反正這事兒我是無所謂啦。
所以如果你覺得普通的資料庫表撐不住了,可以放到 MSSQL/MySQL 的記憶體表裡(不過據說mysql的記憶體表效能提升有限),可以放到 Memcache裡(講真,這個是挺常見的策略),可以放到redis裡(我做過這樣的實現),甚至可以放到 OpenResty 的變數字典裡(只要你有信心不爆記憶體)。

token是個憑條,不過它比門票溫柔多了,門票丟了重新花錢買,token丟了重新操作下認證一個就可以了,因此token丟失的代價是可以忍受的——前提是你別丟太頻繁,要是讓使用者隔三差五就認證一次那就損失使用者體驗了。

基於這個出發點,如果你認為用資料庫來保持token查詢時間太長,會成為你係統的瓶頸或者隱患,可以放在記憶體當中。
比如memcached、redis,KV方式很適合你對token查詢的需求。
這個不會太佔記憶體,比如你的token是32位字串,要是你的使用者量在百萬級或者千萬級,那才多少記憶體。
要是資料量真的大到單機記憶體扛不住,或者覺得一當機全丟風險大,只要這個token生成是足夠均勻的,高低位切一下分到不同機器上就行,記憶體絕對不會是問題。

客戶端方面這個除非你有一個非常安全的辦法,比如作業系統提供的隱私資料儲存,那token肯定會存在洩露的問題。比如我拿到你的手機,把你的token拷出來,在過期之前就都可以以你的身份在別的地方登入。
解決這個問題的一個簡單辦法
1、在儲存的時候把token進行對稱加密儲存,用時解開。
2、將請求URL、時間戳、token三者進行合併加鹽簽名,服務端校驗有效性。
這兩種辦法的出發點都是:竊取你儲存的資料較為容易,而反彙編你的程式hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難,所以終究是防君子不防小人的做法。話說加密儲存一個你要是被人扒開客戶端看也不會被噴明文儲存……
方法1它拿到儲存的密文解不開、方法2它不知道你的簽名演算法和鹽,兩者可以結合食用。
但是如果token被人拷走,他自然也能植入到自己的手機裡面,那到時候他的手機也可以以你的身份來用著,這你就瞎了。
於是可以提供一個讓使用者可以主動expire一個過去的token類似的機制,在被盜的時候能遠端止損。

在網路層面上token明文傳輸的話會非常的危險,所以建議一定要使用HTTPS,並且把token放在post body裡。

 

補充:

cookie與session的區別

1、cookie資料存放在客戶端上,session資料放在伺服器上。

2、cookie不是很安全,別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
   考慮到安全應當使用session。

3、session會在一定時間內儲存在伺服器上。當訪問增多,會比較佔用你伺服器的效能
   考慮到減輕伺服器效能方面,應當使用COOKIE。

4、單個cookie儲存的資料不能超過4K,很多瀏覽器都限制一個站點最多儲存20個cookie。

5、所以個人建議:
   將登陸資訊等重要資訊存放為SESSION
   其他資訊如果需要保留,可以放在COOKIE中

session與token的區別

  session 和 oauth token並不矛盾,作為身份認證 token安全性比session好,因為每個請求都有簽名還能防止監聽以及重放攻擊,而session就必須靠鏈路層來保障通訊安全了。如上所說,如果你需要實現有狀態的會話,仍然可以增加session來在伺服器端儲存一些狀態

  App通常用restful api跟server打交道。Rest是stateless的,也就是app不需要像browser那樣用cookie來儲存session,因此用session token來標示自己就夠了,session/state由api server的邏輯處理。 如果你的後端不是stateless的rest api, 那麼你可能需要在app裡儲存session.可以在app裡嵌入webkit,用一個隱藏的browser來管理cookie session.

  Session 是一種HTTP儲存機制,目的是為無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 資訊儲存到Session 裡,因為SID 的不可預測性,暫且認為是安全的。這是一種認證手段。 而Token ,如果指的是OAuth Token 或類似的機制的話,提供的是 認證 和 授權 ,認證是針對使用者,授權是針對App 。其目的是讓 某App有權利訪問 某使用者 的資訊。這裡的 Token是唯一的。不可以轉移到其它 App上,也不可以轉到其它 使用者 上。 轉過來說Session 。Session只提供一種簡單的認證,即有此 SID,即認為有此 User的全部權利。是需要嚴格保密的,這個資料應該只儲存在站方,不應該共享給其它網站或者第三方App。 所以簡單來說,如果你的使用者資料可能需要和第三方共享,或者允許第三方呼叫 API 介面,用 Token 。如果永遠只是自己的網站,自己的 App,用什麼就無所謂了。

 

打破誤解:

“只要關閉瀏覽器 ,session就消失了?”

不對。對session來說,除非程式通知伺服器刪除一個session,否則伺服器會一直保留,程式一般都是在使用者做log off的時候發個指令去刪除session。

然而瀏覽器從來不會主動在關閉之前通知伺服器它將要關閉,因此伺服器根本不會有機會知道瀏覽器已經關閉,之所以會有這種錯覺,是大部分session機制都使用會話cookie來儲存session id,而關閉瀏覽器後這個session id就消失了,再次連線伺服器時也就無法找到原來的session。如果伺服器設定的cookie被儲存在硬碟上,或者使用某種手段改寫瀏覽器發出的HTTP請求頭,把原來的session id傳送給伺服器,則再次開啟瀏覽器仍然能夠開啟原來的session.

恰恰是由於關閉瀏覽器不會導致session被刪除,迫使伺服器為session設定了一個失效時間,當距離客戶端上一次使用session的時間超過這個失效時間時,伺服器就可以以為客戶端已經停止了活動,才會把session刪除以節省儲存空間

相關文章