JWT vs Session身份驗證：安全性、效能與適用場景分析

在現代網路應用中，身份驗證是一個至關重要的環節。為了在 HTTP 這種無狀態協議下追蹤使用者身份，Session 與 JWT (JSON Web Token) 成為了兩種常見的 ID 卡機制。本文將深入探討這兩種方法的原理、特性與適用場景。

Session ID 卡機制

原理

Session 機制的核心在於伺服器端儲存使用者資訊。當使用者登入後，伺服器會執行以下步驟：

1. 接收使用者提供的帳號密碼，並與資料庫進行比對。
2. 驗證通過後，伺服器會建立一個 Session，並產生一個隨機的 Session ID。
3. 以 Session ID 作為 Key，使用者資訊（例如使用者 ID、使用者名稱等）作為 Value，儲存至 Redis (或其他快取系統)。
4. 將 Session ID 回傳給客戶端。
5. 客戶端將 Session ID 儲存於 Cookie 中。
6. 當使用者請求需要身份驗證的資源時，瀏覽器會將 Cookie 中的 Session ID 放置於請求標頭中發送至伺服器。
7. 伺服器接收到請求後，會從請求標頭中取出 Session ID，並使用該 ID 在 Redis 中查找對應的使用者資訊。
8. 如果找到對應的資訊，則表示使用者已登入，伺服器可以根據使用者資訊判斷使用者是否有權限訪問該資源，並將結果返回給客戶端。

特性

• 需要額外部署 Redis： Session 機制需要額外部署 Redis 或其他快取系統來儲存 Session 資料。雖然對大多數應用來說，部署 Redis 並非難事，但仍需考慮其維護成本。

• 每次訪問都需要讀取 Redis： 每次使用者請求需要身份驗證的資源時，伺服器都需要讀取 Redis 來驗證使用者身份。這會增加訪問延遲，且在高流量情況下，Redis 可能成為效能瓶頸。

• ID 資訊撤回簡單： 如果伺服器發現某個帳號存在安全風險，可以通過刪除 Redis 中對應的 Session ID 來立即撤銷該使用者的身份驗證。

過期時間設定

為了安全考量，Session 通常會設定過期時間。例如，可以設定 30 天的過期時間，這意味著使用者在 30 天內可以保持登入狀態，超過 30 天後，使用者需要重新登入。

JWT ID 卡機制

原理

JWT 是一種基於 Token 的身份驗證機制，它將使用者資訊編碼到 Token 中，並由客戶端儲存。當使用者登入後，伺服器會執行以下步驟：

1. 接收使用者提供的帳號密碼，並進行驗證。

2. 驗證通過後，伺服器會生成一個 JWT Token。JWT Token 通常由三個部分組成：

   • Header (標頭)： 包含 Token 的類型和使用的加密算法。

   • Payload (有效載荷)： 包含使用者資訊，例如使用者 ID、使用者名稱等。

   • Signature (簽名)： 由 Header、Payload 和一個密鑰通過加密算法生成，用於驗證 Token 的完整性和真實性。

   • 將 JWT Token 發送給客戶端。
   • 客戶端將 JWT Token 儲存於本地（通常以 Cookie 形式儲存）。
   • 當使用者請求需要身份驗證的資源時，客戶端會將 JWT Token 放置於請求標頭中發送至伺服器。

   • 伺服器接收到請求後，會驗證 JWT Token 的合法性。驗證過程包括：

   • 使用相同的加密算法和密鑰重新計算簽名，並與 Token 中的簽名進行比對。

   • 檢查 Payload 中的過期時間，判斷 Token 是否已過期。

   • 如果 JWT Token 驗證通過，則表示使用者已登入，伺服器可以根據 Payload 中的使用者資訊判斷使用者是否有權限訪問該資源，並將結果返回給客戶端。

特性

• 使用者認證資訊儲存在客戶端： JWT Token 儲存在客戶端，這意味著伺服器無需儲存 Session 資料，減少了伺服器的儲存壓力。

• 無須與 Redis 互動： 由於使用者資訊儲存在 Token 中，伺服器無需與 Redis 進行互動，減少了訪問延遲。

• ID 資訊撤回困難： 由於 JWT Token 儲存在客戶端，伺服器無法主動撤銷 Token，除非設定較短的過期時間。

• 需要執行加密算法： 為了驗證 JWT Token 的合法性，伺服器需要執行加密算法，這會消耗一定的 CPU 資源。

• Payload 中的資訊容易被攔截： Payload 中的資訊通常使用 Base64 編碼進行傳輸，容易被駭客攔截。因此，Payload 不適合儲存敏感資訊。

安全注意事項

• 使用 HTTPS： 為了防止 JWT Token 在傳輸過程中被竊取，建議使用 HTTPS 協議對所有網路介面進行加密。

• 避免在 Payload 中儲存敏感資訊： Payload 中的資訊容易被攔截，因此不應儲存敏感資訊。如果需要儲存敏感資訊，可以使用加密算法對資訊進行加密。

總結

Session 和 JWT 是兩種不同的身份驗證機制，各有優缺點。選擇哪種機制取決於具體的業務場景。

• Session: 適用於需要頻繁讀取使用者資訊，且對安全性要求較高的場景。

• JWT: 適用於無狀態應用，且對效能要求較高的場景。

在選擇身份驗證機制時，需要綜合考慮安全性、效能、可擴展性等多方面的因素。