Session 的優點與限制

今天我們的任務是要來更了解一點Session。所以，讓我門先回顧一下 Session 機制。

在傳統的 Web 系統中，Session 的出現解決了 Basic Authentication 的最大問題 ——「每次都要傳帳密」。

• 使用者登入後，伺服器建立一個 Session ID。
• 這個 Session ID 透過 Cookie 傳回給瀏覽器，之後每次請求都會自動附帶。
• 伺服器可以透過 Session 記住「這是誰」、「有哪些權限」。

這樣的機制既能避免帳號密碼多次暴露，又能保存狀態，是一個非常好用的方案。

但當系統越來越龐大，Session 就會變成負擔：

1. 記憶體壓力
   • 成千上萬的使用者，每人都會產生一組或多組 Session（手機、電腦、平板）。
   • 所有 Session 都存在伺服器記憶體中，佔用大量資源。
2. 分散式架構的困境
   • 大型系統通常會有多台伺服器，請求可能被分散到不同節點。
   • 如果 Session 沒有同步（例如存在 Redis），就可能完全找不到資料。

這些限制讓工程師開始思考： 能不能不要 Session？

嘗試去除 Session：每次都傳帳密

如果我們拿掉 Session，那會發生什麼事？

答案就是又回到了過去：

• 使用者每次請求都要重新輸入帳密。
• 伺服器每次都要重新驗證帳密。

舉例來說，你要呼叫 /hello API：

• 請求必須帶上 Authorization: user:password。
• 伺服器比對正確，才會放行。

這樣的方式雖然「無狀態」（伺服器完全不記住你），但很快就會出現問題：

1. 效能差
   • 每次請求都要重新比對帳密，伺服器負擔巨大。
2. 不安全
   • 帳密每次都會被傳送，哪怕經過 Base64 編碼，也能輕易被解碼。
   • 一旦外洩，駭客就能無限期冒充使用者。
3. 資訊不足
   • 只能代表「這是誰」，卻無法附帶更多資訊（角色、權限、過期時間）。

所以，雖然這種做法避免了 Session 的記憶體問題，但體驗和安全性都糟糕到不行。

新的方法：「無狀態 Token」

工程師們進一步思考：

「如果使用者不用每次都傳帳密，而是伺服器簽發一個 Token，使用者之後只要帶 Token，就能被認出來，那不就解決了嗎？」

於是有了「無狀態 Token」的概念：

• 伺服器只要產生一個隨機字串（Token）。
• 使用者登入後拿到 Token，之後每次請求帶上即可。
• 伺服器驗證這個 Token 是否有效，就能放行。

聽起來好像很棒，但還是有幾個問題：

1. 資訊不足
   • Token 本身只是個隨機字串，伺服器還是要查資料庫才能知道「這是誰、角色是什麼」。
2. 無法安全失效
   • 一旦 Token 洩漏，就算使用者按下「登出」，Token 在過期前依然能被使用。

於是大家需要一種「自帶資訊」的 Token。

三種認證方式對比

為了幫助理解，我整理了一張比較表：

從我們整理出來的表格可以看出：

• Basic Auth 太危險。
• 無狀態 Token 比較安全，但資訊不足。
• JWT 兼具「無狀態」與「資訊完整」，因此成為主流解法。

總結

今天我們從 Session 的優缺點 出發，模擬了「沒有 Session」的極端情境。

• 去掉 Session 之後，雖然伺服器不用記住使用者，但每次都要傳帳密，效能差、安全性也很糟。
• 無狀態 Token 看似解法，但因為資訊不足、無法控制失效，依然不完美。
• 真正的答案，就是能「自帶資訊」又能「防竄改」的 JWT。

今天的我們更了解了Session跟其他驗證方式的比較，明天，我們將正式進入 JWT 的世界：

• 認識 JWT 的結構（Header / Payload / Signature）。
• 用實例解碼一個 JWT，看看它如何同時攜帶資訊、又能被驗證真偽。

大家明天見！