cookie和session

由於http的無狀態性，為了使某個域名下的所有網頁能夠共享某些資料，session和cookie出現了。客戶端訪問伺服器的流程如下

• 首先，客戶端會發送一個http請求到伺服器端。
• 伺服器端接受客戶端請求後，建立一個session，併發送一個http響應到客戶端，這個響應頭，其中就包含Set-Cookie頭部。該頭部包含了sessionId。Set-Cookie格式如下
  Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
• 在客戶端發起的第二次請求，假如伺服器給了set-Cookie，瀏覽器會自動在請求頭中新增cookie
• 伺服器接收請求，分解cookie，驗證資訊，核對成功後返回response給客戶端

注意

• cookie只是實現session的其中一種方案。雖然是最常用的，但並不是唯一的方法。禁用cookie後還有其他方法儲存，比如放在url中
• 現在大多都是Session + Cookie，但是隻用session不用cookie，或是隻用cookie，不用session在理論上都可以保持會話狀態。可是實際中因為多種原因，一般不會單獨使用
• 用session只需要在客戶端儲存一個id，實際上大量資料都是儲存在服務端。如果全部用cookie，資料量大的時候客戶端是沒有那麼多空間的。
• 如果只用cookie不用session，那麼賬戶資訊全部儲存在客戶端，一旦被劫持，全部資訊都會洩露。並且客戶端資料量變大，網路傳輸的資料量也會變大

小結

簡而言之, session 有如使用者資訊檔案表, 裡面包含了使用者的認證資訊和登入狀態等資訊. 而 cookie 就是使用者通行證

token

token 也稱作令牌，由uid+time+sign[+固定引數]
token 的認證方式類似於臨時的證書籤名, 並且是一種服務端無狀態的認證方式, 非常適合於 REST API 的場景. 所謂無狀態就是服務端並不會儲存身份認證相關的資料。

組成

• uid: 使用者唯一身份標識
• time: 當前時間的時間戳
• sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進位制字串，以防止第三方惡意拼接
• 固定引數(可選): 將一些常用的固定引數加入到 token 中是為了避免重複查庫

存放

token在客戶端一般存放於localStorage，cookie，或sessionStorage中。在伺服器一般存於資料庫中

token認證流程

token 的認證流程與cookie很相似

• 使用者登入，成功後伺服器返回Token給客戶端。
• 客戶端收到資料後儲存在客戶端
• 客戶端再次訪問伺服器，將token放入headers中
• 伺服器端採用filter過濾器校驗。校驗成功則返回請求資料，校驗失敗則返回錯誤碼

token可以抵抗csrf，cookie+session不行

假如使用者正在登陸銀行網頁，同時登陸了攻擊者的網頁，並且銀行網頁未對csrf攻擊進行防護。攻擊者就可以在網頁放一個表單，該表單提交src為http://www.bank.com/api/transfer，body為count=1000&to=Tom。倘若是session+cookie，使用者開啟網頁的時候就已經轉給Tom1000元了.因為form 發起的 POST 請求並不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域傳送 POST 請求，形成 CSRF 攻擊。在post請求的瞬間，cookie會被瀏覽器自動新增到請求頭中。但token不同，token是開發者為了防範csrf而特別設計的令牌，瀏覽器不會自動新增到headers裡，攻擊者也無法訪問使用者的token，所以提交的表單無法通過伺服器過濾，也就無法形成攻擊。

總結

• session儲存於伺服器，可以理解為一個狀態列表，擁有一個唯一識別符號sessionId，通常存放於cookie中。伺服器收到cookie後解析出sessionId，再去session列表中查詢，才能找到相應session。依賴cookie
• cookie類似一個令牌，裝有sessionId，儲存在客戶端，瀏覽器通常會自動新增。
• token也類似一個令牌，無狀態，使用者資訊都被加密到token中，伺服器收到token後解密就可知道是哪個使用者。需要開發者手動新增。