概述

HTTP是一個“無狀態”協議，這意味著Web應用程式伺服器在響應客戶端請求時不會將多個請求連結到任何一個客戶端。然而，許多Web應用程式的安全和正常執行都取決於系統能夠區分使用者並識別使用者及其許可權。

這就需要一些機制來為一個HTTP請求提供狀態。它們使站點能夠在會話期間對各使用者做出適當的響應，從而保持跟蹤使用者在應用程式中的活動（請求和響應）。

伺服器如何驗證token

客戶訪問服務端，服務端給客戶端一個包含少量客戶資訊的字串，如包含客戶ID，當客戶在未退出出瀏覽器的情況下再次訪問伺服器時，需要攜帶token訪問，這時伺服器端解碼token，同伺服器資料庫中比對資訊 同cookie不同的是伺服器不需要建立額外的session來儲存驗證資訊來和cookie呼應，減少了額外儲存壓力

cookie和token

基於cookie的身份驗證

cookie是源自站點並由瀏覽器儲存在客戶計算機上的簡單檔案。它們通常包含一個名稱和一個值，用於將客戶端標識為對站點具有特定許可權的特定使用者。

cookie與源域相連線的方式可以確保僅源域能夠訪問其中儲存的資訊。第三方伺服器既不能讀取也不能更改使用者計算機上該域的cookie內容。

網景公司的前僱員於1993年發明了cookie。

基於cookie的驗證是有狀態的，就是說驗證或者會話資訊必須同時在客戶端和服務端儲存。這個資訊服務端一般在資料庫中記錄，而前端會儲存在cookie中。

驗證的一般流程如下：

1. 使用者輸入登陸憑據；
2. 伺服器驗證憑據是否正確，並建立會話，然後把會話資料儲存在資料庫中；
3. 具有會話id的cookie被放置在使用者瀏覽器中；
4. 在後續請求中，伺服器會根據資料庫驗證會話id，如果驗證通過，則繼續處理；
5. 一旦使用者登出，服務端和客戶端同時銷燬該會話。

基於token的身份驗證

隨著單頁面應用程式的流行，以及Web API和物聯網的興起，基於token的身份機制越來越被大家廣泛採用。

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

基於token的驗證是無狀態的。伺服器不記錄哪些使用者已登陸或者已經發布了哪些JWT。對伺服器的每個請求都需要帶上驗證請求的token。該標記既可以加在header中，可以在POST請求的主體中傳送，也可以作為查詢引數傳送。

工作流程如下：

1. 使用者輸入登陸憑據；
2. 伺服器驗證憑據是否正確，然後返回一個經過簽名的token；
3. 客戶端負責儲存token，可以存在local storage，或者cookie中；
4. 對伺服器的請求帶上這個token；
5. 伺服器對JWT進行解碼，如果token有效，則處理該請求；
6. 一旦使用者登出，客戶端銷燬token。

token相對cookie的優勢

無狀態

基於token的驗證是無狀態的，這也許是它相對cookie來說最大的優點。後端服務不需要記錄token。每個令牌都是獨立的，包括檢查其有效性所需的所有資料，並通過宣告傳達使用者資訊。

伺服器唯一的工作就是在成功的登陸請求上籤署token，並驗證傳入的token是否有效。

防跨站請求偽造（CSRF）

舉個CSRF攻擊的例子，在網頁中有這樣的一個連結
![](http://bank.com?withdraw=1000&to=tom)，假設你已經通過銀行的驗證並且cookie中存在驗證資訊，同時銀行網站沒有CSRF保護。一旦使用者點了這個圖片，就很有可能從銀行向tom這個人轉1000塊錢。

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

多站點使用

cookie繫結到單個域。foo.com域產生的cookie無法被bar.com域讀取。使用token就沒有這樣的問題。這對於需要向多個服務獲取授權的單頁面應用程式尤其有用。

使用token，使得用從myapp.com獲取的授權向myservice1.com和myservice2.com獲取服務成為可能。

支援移動平臺

好的API可以同時支援瀏覽器，iOS和Android等移動平臺。然而，在移動平臺上，cookie是不被支援的。

效能

一次網路往返時間（通過資料庫查詢session資訊）總比做一次HMACSHA256計算的Token驗證和解析要費時得多。