前言

昨天我們實作了 Basic Authentication，體驗到「每次請求都要帶帳號密碼」的麻煩。

因此，Web 系統後來發展出 Session 機制：

• 使用者只要登入一次，伺服器就會「記住」你。
• 瀏覽器會自動帶上 Cookie，讓伺服器知道「這個人已經登入過了」。

接下來就讓我們來開始介紹Cookie跟Session吧！

Cookie 與 Session 的角色分工

1. Session（伺服器端的記憶）
   • 當使用者登入成功後，伺服器會產生一個 Session ID。
   • 這個 Session ID 存在伺服器的記憶體（或資料庫）。
2. Cookie（瀏覽器端的憑證）
   • 伺服器會把 Session ID 傳給瀏覽器，存在 Cookie 裡。
   • 瀏覽器之後每次請求 API 時，會自動把 Cookie 帶上來。

這樣一來，使用者就不用重複輸入帳號密碼，伺服器也能辨認「這個人已經登入過了」。

整體來說，整個Cookie Based Authentication的流程如下：

1. 使用者輸入帳號密碼 → 登入
2. 伺服器驗證正確後 → 建立 Session → 分配一個 SESSION_ID
3. 瀏覽器收到回應 → 把 SESSION_ID 存在 Cookie
4. 之後每次 API 請求 → 瀏覽器自動附帶 Cookie
5. 伺服器根據 SESSION_ID → 知道這個人是誰

範例：

Client: POST http://localhoat:8080/login
       { "username": "ithome", "password": "secret" }
Server: 驗證成功 → 建立 Session
       Response: Set-Cookie: JSESSIONID=abc123
Client: GET http://localhoat:8080//hello
       Cookie: JSESSIONID=abc123
Server: 查 Session → 驗證通過 → 回應資料

那這個與Basic相比，有什麼差別呢，我們可以從攜帶的資訊，儲存的位置來看這兩者個差異，可以看這個表：

安全性問題

雖然 Session 機制比 Basic Auth 好很多，但仍然有幾個需要注意的風險：

1. CSRF（Cross-Site Request Forgery，跨站請求偽造）
   • 瀏覽器會自動帶 Cookie，所以如果使用者點了惡意網站連結，Cookie 也會被帶過去。
   • 解法：加入 CSRF Token 驗證。
2. Session 劫持
   • 如果駭客偷走了 Cookie（例如透過 XSS），就能冒充使用者。
   • 解法：設定 HttpOnly / Secure / SameSite 屬性，避免 Cookie 被竊取。
3. 伺服器壓力
   • 因為伺服器要存 Session，如果同時有上萬人登入，伺服器就要維護上萬個 Session。
   • 這也是為什麼後來出現 Token / JWT 的原因 —— 減少伺服器記憶負擔。

這裏的CSRF網路上有很多人解釋，詳細的技術我會推薦大家自己用關鍵字查找，會能夠更加理解關於CSRF,跟如何確保安全性的方法。

總結

• Cookie + Session 是 Web 登入機制的基礎。
• 相比 Basic Auth，它的體驗更好（不用一直重複輸入帳號密碼）。
• 但因為需要伺服器保存狀態，仍有安全性與效能挑戰。

相信看到這裡，你肯定已經有了明確的概念，但會想要知道要怎麼樣實作，於是明天，我們會用 Spring Boot Security 來實際做一次 Cookie Based Authentication。

你將會看到：

• Spring Security 如何幫我們自動管理 Session。
• 登入後如何在瀏覽器的 Cookie 裡看到 JSESSIONID。
• API 在沒有登入與登入後的差異。

今天我們就到這裡，讓我高歌離席，期待明天與各位再相見！