憑證管理揭秘：Cookie-Session 與 JWT 方案的對決

作者：肖衛衛 2024-04-26 12:45:39

在互聯網早期，這個問題早就有了明確的答案。大多數應用都采用了 “Cookie-Session” 的方法，這種方法通過在服務器上存儲用戶狀態，來實現用戶身份的識別和信息的傳遞。這種方法在很長一段時間里都是主流。

概述

在上一篇文章我們聊完了授權的過程，在服務器對客戶端完成授權之后，服務器會給客戶端頒發對應的憑證，客戶端持有該憑證訪問服務端，服務器便能知道你是誰，你有什么權限等信息。這一章我們具體聊聊常見的憑證管理技術有哪些。

在軟件架構中，關于憑證如何存儲和傳遞，一直有兩種不同的解決思路，兩種不同的解決方式，實際上反映了兩種不同的架構思路：

一種是把所有狀態信息都放在服務器端（Cookie-Session 方案）
一種是把所有狀態將信息存儲在客戶端（JWT 方案）

然而，隨著微服務和分布式系統的興起，我們發現由于 CAP 的限制，服務器端存儲狀態信息的方式開始面臨很多問題（微服務要求服務端本身是無狀態，才能實現動態擴縮容）。這就迫使我們重新考慮被放棄的客戶端狀態存儲方法。在這個背景下，JWT（JSON Web Token）的令牌的方案開始受到關注。JWT 是一種在客戶端存儲用戶狀態信息的方式，它允許用戶在不同的服務器之間自由切換，而不需要重新登錄。這種特性在分布式系統中非常有用。但是要明白，JWT 和 Cookie-Session 只是對授權信息存儲的主體（客戶端，服務端）不同，各有優勢，合適場景不同，不存在誰比誰要先進的問題。在本節中，我們將探討 Cookie-Session 和 JWT 兩種方案的相同點和不同點，幫你更好地理解這兩種方案的優缺點，以及它們在不同場景下的應用。

cookie-session

總所周知，因為 HTTP 是無狀態協議，所以 Cookie-Session 的原理其實很簡單，就是解決 HTTP 協議無狀態的問題，在 RFC 6265 中定義了 HTTP 的狀態管理機制，增加 Set-Cookie 指令，服務端向客戶端發送一組信息（標識）示例：

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: session_token=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT; Path=/

客戶端收到指令后在此后一段時間的 HTTP 請求中都發給服務端會話信息（在 Header 中攜帶 cookie 信息），以便服務器區分不同的客戶端：

GET /profile HTTP/1.1
Host: www.example.com
Cookie: sessionid=xyzasdzxc123789456

客戶端的 Cookies 里通常只存儲一個無意義，不重復的字符串，通常命名是 sessionid 或 jessionid ，服務端則根據該字符串作為 Key，和用戶信息建立關聯后存儲在服務端的內存或者緩存中。再輔以一些超時自動清理的措施來管理會話。

它們的交互過程如下：

圖片

這種服務端的狀態管理機制就是 Session，Cookie-Session 也是最傳統，但今天依然廣泛應用于大量系統中的，由服務端與客戶端聯動來完成的狀態管理機制。

總結

cookie-session 的方案在存儲授權信息具有以下優勢：

安全性：由于狀態信息都存儲在服務端，cookie-session 方案在安全性上有天然的優勢，能完全規避上下文信息在傳輸過程中被篡改的風險
靈活性：由于存儲在服務端，服務端可以存儲各種數據對象，而不僅僅是字符串
狀態控制：服務端維護狀態的優勢在于可以根據自己的意愿隨時修改，清除上下文信息，可以很輕松實現用戶強制下線的功能。

Cookie-Session 在單體服務環境中是最合適的方案，但是因為服務端有狀態，當需要水平擴展服務能力，要部署集群時就開始面臨麻煩了。接下來的 JWT 令牌就是 Cookie-Session 在分布式環境的替代品，但是不能說 JWT 要比 Cookie-Session 更加先進，更不可能全面取代 Cookie-Session 機制。

JWT

當服務端有多臺，并且不能存儲狀態的時候，客戶端就要承擔存儲有狀態（授權信息）的職責了。這就是 JWT 令牌的方案思路。

JWT（JSON Web Token）是一種定義在 RFC 7519 標準中的令牌格式，主要應用于現代分布式應用系統中，經常與 OAuth2 協議配合使用。在深入探討 JWT 的結構之前，我們先來直觀地了解一下它的基本形式。示例：

圖片

注意：JWT 令牌不加密，只使用 Base64URL 轉碼，所以 JWT 令牌里別放敏感信息，令牌只解決防篡改的問題，并不解決防泄漏的問題，JWT 令牌都可以在 JWT 官網（https://jwt.io）上進行解碼。如圖所示，JWT（JSON Web Token）由三部分組成：Header（頭部）、Payload（負載）、Signature（簽名）。這三部分之間使用點（.）分隔。

Header：Header 部分通常包含令牌的類型（通常是 JWT）和使用的加密算法，例如 HS256：

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

Payload：Payload 部分包含所需的聲明，這些聲明可以包括用戶信息或其他相關數據。例如，用戶ID和過期時間：

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

負載部分，JWT 在 RFC 7519 中推薦（非強制約束）了七項聲明名稱（Claim Name），如有需要用到這些內容，建議字段名與官方的保持一致：

iss（Issuer）：簽發人。
exp（Expiration Time）：令牌過期時間。
sub（Subject）：主題。
aud （Audience）：令牌受眾。
nbf （Not Before）：令牌生效時間。
iat （Issued At）：令牌簽發時間。
jti （JWT ID）：令牌編號。

此外在 RFC 8225、RFC 8417、RFC 8485 等規范文檔，以及 OpenID 等協議中，都定義有約定好公有含義的名稱，可以參考 IANA JSON Web Token Registry。

Signature：Signature 是使用 Header 中指定的算法和一個密鑰對 Header 和 Payload 進行簽名得到的。對前面兩部分內容進行加密計算，以例子里使用的 JWT 默認的 HMAC SHA256 算法為例，將通過以下公式產生簽名值：

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

簽名的意義在于確保負載中的信息是可信的、沒有被篡改的，也沒有在傳輸過程中丟失任何信息。因為被簽名的內容哪怕發生了一個字節的變動，也會導致整個簽名發生顯著變化。JWT 默認使用的 HMAC SHA256 算法是一種密鑰哈希算法，適用于單體應用中，因為加密和驗證都需要由同一授權服務完成。在多方或分布式應用中，通常使用非對稱加密算法進行簽名。這種情況下，授權服務使用私鑰簽名，并通過遵循 JSON Web Key 規范公開一個公鑰。這個公鑰用于驗證簽名，使其他服務能夠獨立驗證 JWT 的真實性，無需直接與授權服務通信。

JWT 令牌的交互流程如下：

圖片

說明：如果是在分布式環境下，通常會有單獨的認證服務器來負責頒發令牌。

發送令牌

按照 HTTP 協議的規范，客戶端可以通過多種方式使用 HTTP 協議發送 JWT 令牌給服務端。最標準的方式是將 JWT 放在 HTTP 的 Authorization 頭部中，通常與 Bearer 方案一起使用。這種方法簡單且符合 RESTful API 的最佳實踐：

GET /api/resource HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIx......

總結

JWT 令牌是分布式系統下憑證載體的優秀解決方案，它優點眾多：

解決了分布式系統下的狀態信息的管理問題，讓服務端無狀態，實現動態擴縮容。
結構簡單，輕量，憑證本身包含重要信息，服務端無需再查詢數據庫
通過密鑰對和簽名的方式，保證憑證信息的無法被篡改，保證了憑證的真實性

但是沒有完美的解決方案，cookie-session 的優點也 JWT 也缺點：

會話難以主動失效：服務端難以注銷令牌，如果非要實現，就要把狀態信息轉移存儲到 redis 中。
攜帶的信息有限：雖然 HTTP 沒有限制 Header 中可存儲的大小限制，但是 HTTP 服務端大多都有存儲上限，例如 tomcat 限制 8kb，nginx 限制 4kb
客戶端令牌泄露風險：客戶端令牌存在哪里？Cookie ? localStrong ? Indexed ? 存在哪里都有泄露風險。只要拿到令牌就能冒認客戶端身份
服務端無狀態會導致很多常見的功能難以實現，例如：踢人下線，統計在線人數等等。。

責任編輯：武曉燕來源：肖衛衛講編程