JWT vs 工作階段：2025 年選擇哪一個？
12 min read
JWT, Security, Authentication
理解認證方法
在 2025 年，開發者繼續在 JWT（JSON Web Token）和傳統基於工作階段的認證之間進行辯論。兩種方法都有其優點和權衡，正確的選擇取決於您的特定使用案例、架構和安全需求。本文提供了全面的比較，幫助您做出明智的決定。
基於工作階段的認證
傳統的基於工作階段的認證已經存在了幾十年，並且仍然廣泛使用。
運作原理
- 使用者提供憑證（使用者名稱/密碼）
- 伺服器驗證憑證並建立工作階段
- 工作階段 ID 儲存在伺服器端（記憶體、資料庫、Redis）
- 工作階段 ID 作為 cookie 傳送給客戶端
- 客戶端在後續請求中傳送 cookie
- 伺服器查詢工作階段儲存以驗證工作階段
優點
- ✅ 立即撤銷：可以立即使工作階段失效
- ✅ 簡單實施：大多數框架內建支援
- ✅ 較小的請求大小：只傳送工作階段 ID
- ✅ 伺服器端控制：對工作階段資料的完全控制
缺點
- ❌ 伺服器端儲存：需要記憶體/資料庫儲存
- ❌ 擴充挑戰：跨多個伺服器的工作階段共享
- ❌ CORS 複雜性：跨域請求的 Cookie 處理
- ❌ 行動應用程式限制：原生應用程式中的 Cookie 處理
JWT 認證
JWT 提供了一種無狀態的認證方法，在微服務和分散式系統中越來越受歡迎。
運作原理
- 使用者提供憑證
- 伺服器驗證並產生簽章的 JWT
- JWT 傳送給客戶端
- 客戶端儲存 JWT（localStorage、記憶體、cookie）
- 客戶端在 Authorization 標頭中傳送 JWT
- 伺服器驗證 JWT 簽章和聲明
優點
- ✅ 無狀態：無需伺服器端工作階段儲存
- ✅ 可擴充：非常適合微服務架構
- ✅ 跨域友好：在標頭中輕鬆傳送
- ✅ 行動應用程式友好：原生支援權杖
- ✅ 解耦：認證與應用程式分離
缺點
- ❌ 無法撤銷：權杖在過期前有效
- ❌ 較大的大小：包含所有使用者資料
- ❌ 安全考量：需要仔細處理和儲存
- ❌ 複雜性：需要權杖重新整理邏輯
詳細比較
效能比較
| 方面 | 工作階段 | JWT |
|---|---|---|
| 資料庫查詢 | 每個請求 | 無 |
| 網路負載 | 小（~50 位元組） | 大（~500-2000 位元組） |
| CPU 使用 | 低 | 中等（簽章驗證） |
| 記憶體使用 | 高（工作階段儲存） | 低 |
安全比較
| 威脅 | 工作階段 | JWT |
|---|---|---|
| XSS | 透過 HttpOnly cookies 受保護 | 如果在 localStorage 中易受攻擊 |
| CSRF | 易受攻擊（需要 CSRF 權杖） | 如果不使用 cookies 則免疫 |
| 重播攻擊 | 工作階段 ID 輪換 | 需要短過期時間 |
| 權杖/工作階段劫持 | 可以立即撤銷 | 在過期前有效 |
何時使用工作階段
- 📌 單體應用程式與單一伺服器
- 📌 需要立即工作階段撤銷
- 📌 處理敏感資料需要嚴格控制
- 📌 簡單的傳統網頁應用程式
- 📌 有限的客戶端儲存需求
何時使用 JWT
- 📌 微服務架構
- 📌 單頁應用程式 (SPA)
- 📌 行動應用程式
- 📌 跨域 API 請求
- 📌 無狀態的 RESTful API
- 📌 需要水平擴充
混合方法
許多現代應用程式使用混合方法：短期 JWT 配合儲存為安全 HTTP-only cookie 的重新整理權杖。這結合了兩種方法的優點。