前兩天我們新學了JWT與Session，因此今天我們就要比較兩者，首先要先簡單講一下為什麼兩者會經常放在一起比較，其實是因為這兩者的存在都是為了解決同一個問題，也就是如何讓伺服器知道用戶是誰?不過兩者走的路線不太一樣，所以我們今天會從幾個方面來比較兩者的不同。

兩者的共同需求

在網路當中，HTTP協議是無狀態(stateless)的，例如伺服器每次收到請求都不會知道使用者剛剛是否登入過，也就是說在這背後會出現一個需求，也就是需要一種身分驗證的機制，使伺服器能夠認得每一個用戶。而Session與JWT都是解決這個問題的方案。

比較

雖然有一些點前兩天有先講過，但是這邊為了方便比較還是都會寫出來

1.設計思維

• Session
  伺服器記住使用者狀態
  用戶端僅保存Session ID，其餘資料皆存於伺服端
  基本上伺服器即為單一權威

• JWT
  讓使用者自行證明
  用戶端保存完整Token，伺服器的工作室驗證真偽
  偏向去中心化，較適合分散式的架構

2.安全性

• Session
  資料存於伺服器，不會直接暴露
  Cookie只保存一串隨機 ID，外洩時只要伺服器刪掉Session就能立即失效
  較容易因 Session Fixation、CSRF 遭攻擊，但有SameSite Cookie等防禦方式

• JWT
  Token通常放在HTTP Header (Authorization: Bearer …)或Cookie
  Token包含敏感資訊（僅Base64 編碼，非加密），必須搭配HTTPS避免竊聽
  洩漏後難以撤銷，必須設計黑名單、短效存活時間、Refresh Token 機制

3.效能

• Session
  每次請求都要查伺服器端 Session 資料
  如果Session 存在資料庫或Redis，會增加查詢負擔
  當使用者數量非常大時，伺服器內存壓力上升

• JWT
  伺服器只需要驗證簽章(通常用HMAC-SHA256或RSA/ECDSA)，效能很快，不必查資料庫
  Token本身較大，會消耗較多流量
  適合「多次API請求」的情境

4.使用情境

• Session
  傳統網站(購物車、論壇、公司內部系統)
  使用者數量有限，或伺服器有Redis、Memcached可做Session分散式管理
  洩漏時需「立即撤銷」的情境(如銀行系統、後台管理)

• JWT
  行動應用(App登入後直接拿Token呼叫API)
  微服務架構(多個服務共享JWT驗證，不需共享Session資料庫)
  OAuth 2.0 / OpenID Connect 等身份驗證協議(Google/Facebook 登入)

5.擴展性

• Session
  當系統需要橫向擴充(多台伺服器)，必須做Session同步
  擴展限制較多，擴展性較差

• JWT
  天生適合分散式環境，因為Token自己包含資訊
  缺點是難以精細控管權限(例如修改使用者角色後，舊 Token 仍然有效，直到過期才會反映變更)

6.實務應用

• Session
  在傳統Web專案中非常常見，PHP、ASP.NET、Django 都有內建Session機制
  在需要「強制登出」「即時權限更新」時，Session的可控性比JWT好很多

• JWT
  常見於在前後端分離(SPA + API)專案中
  常搭配 短效 Access Token + 長效 Refresh Token
  Access Token：存活 5–15 分鐘，降低洩漏風險。
  Refresh Token：存活幾天到幾週，專門用來換新 Access Token。
  一般會把 敏感權限判斷 交回伺服器端處理，而不是完全依賴 Token 的 payload

7.現狀

綜合以上特性，目前許多企業都會將兩者混用，使兩者的優勢發會到最大，例如用JWT做API驗證，用Session控制後台登入

今日小結

今天我們學了Session與JWT各方面的優缺點，目的是希望大家對於兩者之間的關係以及應用場景更加熟悉，之後能夠更加熟練地運用兩者。