前言

本文將首先概述基於cookie的身份驗證方式和基於token的身份驗證方式，在此基礎上對兩種驗證進行比較。
最後將介紹JWT（主要是翻譯官網介紹）。

概述

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

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

cookie和token

下面兩圖大致展示了基於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驗證和解析要費時得多。

JWT

JWT是JSON Web Token的縮寫。它定義了一種緊湊且獨立的方式，用於將各方之間的資訊保安地傳輸為JSON物件。這是一個開放的標準，見RFC 7519。

基於JWT的資訊可以通過數字簽名進行校驗。校驗的方法即可以使用訊息摘要（HMAC），或者非對稱加密（RSA）。

JWT具有兩個特點：

1. 緊湊。由於其較小的尺寸，JWT可以通過URL，POST引數或者HTTP頭髮送。較小的尺寸會帶來傳輸速度的優勢；
2. 自包含：token中包含了使用者的所有必須資訊，避免了多次查詢資料庫的需要。

應用場景

以下是JWT有用的一些場景

1. 驗證：這是JWT最常用的場景。一旦使用者登陸成功，每個後續的請求將包括JWT，伺服器在對JWT進行驗證後，允許使用者訪問服務和資源。單點登陸是一個廣泛使用JWT的場景，因為它的開銷相對較小，並且能夠在不同的域中輕鬆使用。
2. 資訊交換：JWT是在可以安全地傳輸資訊。因為JWT可以被簽名，收信人可以確認發信人的身份，同時也能夠驗證內容是否被篡改。

格式

JWT包括三個部分：頭部、載荷和簽名，這三個部分通過.連線起來。

因此，一個典型的JWT長這樣xxxxx.yyyyy.zzzzz。

頭部

頭部通常包括兩部分：token型別（JWT），和使用到的演算法，如HMAC、SHA256或RSA，下面是一個例子，說明這是一個JWT，使用的簽名演算法是HS256。

{
  "alg": "HS256",
  "typ": "JWT"
}

頭部會通過Base64Url編碼形成JWT的第一部分

載荷

第二部分是載荷，要傳遞出去的宣告，其中包含了實體（通常是使用者）和附加元資料。有三種類型的宣告：

• 保留宣告：這是一組預定義的宣告，非強制性，用來幫助接收方（伺服器）更好地理解這個JWT。其中包括：iss（issuer，該JWT的簽發者），exp（expiration time，過期時間），sub（subject，該JWT所面向的使用者），aud（audience，JWT的接收者），和另外一些宣告
• 公共宣告：這些可以用使用JWT的人隨意定義。但是為了避免衝突，應在在IANA JSON WEB令牌登錄檔中定義它們，或者將其定義為包含防衝突名稱空間的URI。
• 私有宣告：這些是為了在同意使用它們的各方之間共享資訊而建立的自定義宣告。

下面是一個例子

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

載荷會通過Base64Url編碼形成JWT的第二部分

簽名

將上面兩部分編碼後，使用.連線在一起，形成了xxxxx.yyyyyy。

最後，採用頭部指定的演算法，和私鑰對上面的字串進行簽名。

加入採用的是HMAC SHA256 演算法，簽名將通過下面的方式生成

HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

該簽名使用者驗證JWT傳送者的身份，並確保該訊息沒有被篡改。

JWT工作流程

在身份驗證過程中，一旦使用者使用其憑據成功登陸，伺服器將返回JWT，該JWT必須在客戶端本地儲存。這和伺服器建立會話並返回cookie的傳統方法不同。

每次使用者要請求受保護的資源時，必須在請求中帶上JWT。通常在Authorization頭Bearer中，如下：

Authorization: Bearer <token>

這是一種無狀態的認證機制，因為使用者狀態永遠不會儲存在伺服器記憶體中。伺服器的受保護路由將在授權頭中檢查有效的JWT，如果存在，則允許使用者訪問受保護的資源。由於JWT是自說明的，包含了所有必要的資訊，這就減少了多次查詢資料庫的需要。

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

整個流程如下圖：

使用JWT的理由

現在來談談JWT與簡單網頁令牌（SWT）和安全斷言標記語言令牌（SAML）相比的優勢。

由於JSON比XML更短小，編碼時其大小也較小，使得JWT比SAML更緊湊。這使得JWT成為在HTML和HTTP環境中能更快地傳遞。

從安全形度來說，SWT只能通過使用HMAC演算法的共享金鑰進行對稱簽名。但是，JWT和SAML令牌可以以X.509證書的形式使用公鑰/私鑰對進行簽名。與簡單的JSON簽名相比，使用XML數字簽名簽名XML而不引入模糊的安全漏洞是非常困難的。

JSON解析器在大多數程式語言中很常見，因為它們直接對映到物件。相反，XML沒有自然的文件對物件對映。這使得使用JWT比SAML斷言更容易。

從使用平臺來說，JWT在Internet規模上使用。這突出了客戶端處理多個平臺上特別是移動平臺上的JSON Web令牌的便利性。