session-based 與 token-based 的驗證，有什麼不同?
2025年8月5日
談到軟體應用程式開發，就免不了談登入 (驗證) 這個主題。所謂的驗證 (authentication) 做的事情是驗證你的身分，白話來說就是讓系統知道你是你，而不是別人。在登入時輸入帳號密碼，即是一種驗證你確實是你的方式 (假設在安全的狀況下，只有你知道你的帳號密碼，所以可以藉此驗證)。
授權 (authorization) 則是涉及你有什麼權限。在系統確認你確實是你後，系統會需要進一步判斷你有什麼權限，並基於你有的權限，開放讓你能做不同的操作。
在這篇文章，我們主要會討論前者，談不同角度切入的驗證模式，不會談及「驗證成功後，這位使用者有哪些權限可以做哪些事」。
此外，中文常會把 verification 也翻譯成驗證，但在寫這篇文章前查證過，繁體中文圈目前對 authentication 的翻譯多數都選用「驗證」，包含 Google 或 Microsoft 的技術文件翻譯都選這個詞。所以文章中提到「驗證」都是指 authentication 而不是 verification。
什麼是 session-based 驗證?
session-based 如下圖所示，這種驗證方式最基本的運作，是使用者第一次登入時，伺服器端會生一個對應的 session，然後會有相關的 session ID，並且會透過 HTTP 的 Set-Cookie 在瀏覽器的 cookie 中存下這個 session ID。
在這之後，因為發送請求時，瀏覽器會自動帶上這個 cookie，所以使用者就不需用每次進到畫面，就必須重新輸入帳號密碼，省下許多麻煩。
session-based 的驗證機制，有更多其他潛在的問題。其中一個對後端來說比較麻煩的問題，是隨著網頁應用的市場發展逐漸成熟，單一的伺服器變得不足以應付逐漸變大的流量；於是越來越多透過水平擴展 (horizontal scaling) 的方式，用多台伺服器來處理來自使用者的請求。
這時問題就來了，因為 session 是由單一伺服器管理的，如果有多台伺服器，就會有 session 要如何處理的問題。一個做法是確保同一個使用者的請求都進到同個伺服器 (俗稱 sticky session 的做法)，或是像用額外的存儲機制來處理(俗稱 session store 的做法)， 每次要驗證時就先去跟那個中央存儲機制拿，但這兩種做法都會讓整體系統的複雜度變高。
除此之外，兩個做法都會有潛在的單點故障問題 (single point of failure)，因為把同使用者的請求都送到同台伺服器上，如果該伺服器掛了，那使用者的請求別台伺服器沒辦法處理；如果用 session store 這種做法，可能會用 Redis，假如 Redis 掛了，那這樣其他伺服器就沒辦法處理同一個 session。
token-based 驗證機制
前面的段落提到 session-based 的驗證是由 cookie 中帶上 session ID，然後由伺服器端透過 session ID 去處理驗證。而 token-based 的驗證方式，則是以 token 做為辨識使用者的方式。
具體來說，客戶端會在登入後，拿到 token，然後再後續的請求，都會戴上 token，而伺服器端驗證 token 即可，因此使用者不用每次都得輸入帳號密碼來驗證。
這兩種驗證方式最主要的區別在於是否有「狀態」，在 sesison-based 的驗證方式下，伺服器端會維持 session 的狀態，也因為這個特性，導致前面提到的擴展時的問題 。而 token-based 的驗證方式，則不需用額外維持狀態，而是直接透過 token 來進行驗證即可。
重點差異在於狀態維持
上面談到「session-based 的驗證是由 cookie 中帶上 session ID，然後由伺服器端透過 session ID 去處理驗證」，很多讀者可能會問「但我看 token-based 驗證」在
沒錯，即使是 token-based 的驗證方式，也推薦要把 token 存在 cookie 當中，這點我們在《如何設計前端登入機制? 該用 localStorage 還是 cookie 保持登入狀態?》有詳細談。
換句話說 session-based 是把 session ID 放 cookie，token-based 是把 token 放 cookie，不是說用 token-based 就不用 cookie。以 ChatGPT 網頁版來說，就是把 token 放 cookie 來做驗證的例子 (開瀏覽器開發者工具來看就會看到)。
所以這邊區分兩種驗證方式的關鍵，還是在狀態維持與否 (stateful 或 stateless)。當然，純粹的無狀態驗證，也會有問題，所以業界後來才延伸出 access token 搭配 refresh token 這種混合模式。
進一步說，談到透過 token 驗證，相信多數人在碰到這個主題時，或多或少因為各類 token ( bearer token、ID token、access token、refresh token、transparent token、opaque token)，覺得眼花撩亂。
我們在 E+ 成長計畫的主題文，有詳細地談了這些不同 token，分別的作用，以及彼此的關係。如果有興趣更深入理解，歡迎加入 E+ 成長計畫 (連結)