HTTP協議本身是無狀態的，所以需要一個標志來對用戶身份進行驗證

身份驗證方式

• 基于cookie的身份驗證
• • Cookie
  • Session
  • 應用場景
  • CSRF
• 基于token的身份驗證
• • CORS
  • token相對于cookie的優勢

基于cookie的身份驗證

Cookie

???????Cookie 是客戶端的存儲空間，由瀏覽器來維持。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie，當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出去。

??????? Cookie 是服務器生成并發送給客戶端，且由客戶端來保存的。每次請求都需要加上 Cookie。服務器端收到客戶端發送的 Cookie 后，從數據庫中尋找相應的sessionid，檢查究竟是從哪一個客戶端發來的連接請求，得到狀態信息。
單個Cookie 在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能超過3K

Session

??????? Session 保存在服務器中，使用Cookie 作為識別標志。HTTP協議是無狀態的，Session 不能依據HTTP連接來判斷是否為同一客戶，因此服務器向客戶端瀏覽器發送一個名為 JSESSIONID 的 Cookie，它的值為該 Session 的 id（即放在HTTP響應報文頭部信息里的Set-Cookie）。Session依據該 Cookie 來識別是否為同一用戶。

???????基于cookie的驗證是有狀態的，就是說驗證或者會話信息必須同時在客戶端和服務端保存。這個信息服務端一般在數據庫中記錄，而前端會保存在cookie中。

應用場景

登錄網站，今輸入用戶名密碼登錄了，第二天再打開很多情況下就直接打開了。這個時候用到的一個機制就是cookie。

session一個場景是購物車，添加了商品之后客戶端處可以知道添加了哪些商品，而服務器端如何判別呢，所以也需要存儲一些信息就用到了session。

基于cookie的身份驗證方式很容易受到CSRF（防跨站請求偽造）攻擊，因此需要使用基于token的身份驗證方式

CSRF

???????跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。

攻擊過程舉例：
???????假設你已經通過銀行的驗證并且cookie中存在驗證信息，同時銀行網站沒有CSRF保護。一旦用戶點了這個圖片（連接為【http://bank.com?withdraw=1000&to=tom】），就很有可能從銀行賬戶向tom轉1000塊錢。

防止CSRF攻擊的方式：

驗證碼

Token
?如果銀行網站使用了token作為驗證手段，攻擊者將無法通過上面的鏈接轉走你的錢。（因為攻擊者無法獲取正確的token）

詳見怎么防止跨站請求偽造攻擊（CSRF）？

基于token的身份驗證

???????當討論基于token的身份驗證時，一般都是說的JSON Web Tokens（JWT）。雖然有著很多不同的方式實現token，但是JWT已經成為了事實上的標準，所以后面會將JWT和token混用。

???????請求登錄時，token和sessionId原理相同，是對key和key對應的用戶信息進行加密后的加密字符，登錄成功后，會在響應主體中將{token：‘字符串’}返回給客戶端。客戶端通過cookie、sessionStorage、localStorage都可以進行存儲。再次請求時不會默認攜帶，需要在請求攔截器位置給請求頭中添加認證字段Authorization攜帶token信息，服務器端就可以通過token信息查找用戶登錄狀態。

???????JWT是一種無狀態的認證機制，因為用戶狀態永遠不會保存在服務器內存中。服務器不記錄哪些用戶已登陸或者已經發布了哪些JWT。對服務器的每個請求都需要帶上驗證請求的token。該標記既可以加在header中，可以在POST請求的主體中發送，也可以作為查詢參數發送。服務器的受保護路由將在授權頭中檢查有效的JWT，如果存在，則允許用戶訪問受保護的資源。由于JWT是自說明的，包含了所有必要的信息，這就減少了多次查詢數據庫的需要。

???????這樣可以完全依賴無狀態的數據API，甚至可以向下游服務發出請求。API的作用域并不重要，因此跨源資源共享（CORS）不會是一個問題，因為它不使用Cookie。

CORS

??CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。它允許瀏覽器向跨源服務器，發出XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。

瀏覽器將CORS請求分成兩類：

• 簡單請求（simple request）
  ? 對于簡單請求，瀏覽器直接發出CORS請求。具體來說，就是在頭信息之中，增加一個Origin字段用來說明，本次請求來自哪個源（協議 + 域名 + 端口）。服務器根據這個值，決定是否同意這次請求：
  • 如果Origin指定的源，不在許可范圍內，服務器會返回一個正常的HTTP回應；
  • 如果Origin指定的域名在許可范圍內，服務器返回的響應，會多出幾個頭信息字段。
• 非簡單請求（not-so-simple request）
  ??非簡單請求是那種對服務器有特殊要求的請求，比如請求方法是PUT或DELETE，或者Content-Type字段的類型是application/json。
  ??非簡單請求的CORS請求，會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight。
  ??瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。
  ?? "預檢"請求用的請求方法是OPTIONS，表示這個請求是用來詢問的。頭信息里面，關鍵字段是Origin，表示請求來自哪個源。

詳見 跨域資源共享 CORS 詳解.

---

token相對于cookie的優勢

基于token的驗證是無狀態的，這也許是它相對cookie來說最大的優點。后端服務不需要記錄token。每個令牌都是獨立的，包括檢查其有效性所需的所有數據，并通過聲明傳達用戶信息。
服務器唯一的工作就是在成功的登陸請求上簽署token，并驗證傳入的token是否有效。

支持跨域訪問，cookie會綁定到單個域。foo.com域產生的cookie無法被bar.com域讀取。使用token就沒有這樣的問題。這對于需要向多個服務獲取授權的單頁面應用程序尤其有用。
使用token，使得用從myapp.com獲取的授權向myservice1.com和myservice2.com獲取服務成為可能。

更適用于移動端 （Android，iOS，小程序等等），像這種原生平臺不支持cookie，比如說微信小程序，每一次請求都是一次會話。

性能更好，效率更高，一次網絡往返時間（通過數據庫查詢session信息）總比做一次HMACSHA256計算的Token驗證和解析要費時得多。

避免CSRF跨站偽造攻擊 ，還是因為不依賴cookie；

參考：
token和session的區別 .
Cookie和Token.
前后端分離 token和cookie對比.

總結

以上是生活随笔為你收集整理的Cookie、Session和Token（学习笔记）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。