主流網站瀏覽器端為何不採用 JWT：一篇技術文章掀起的認證方案討論整理

2026年9月12日，中國技術社羣掘金出現一篇標題為「被吹上天的 JWT，為什麼主流網站一個都不用」的長文，作者署名「減瓦」。文章以瀏覽器開發者工具的實際觀察為起點，主張主流網站的瀏覽器端認證幾乎全數採用服務端 Session 搭配 Cookie，JWT（JSON Web Token）在教學與面試題中的高曝光與真實生產環境的用法之間存在落差。本文綜合該篇文章與其引用的各方訊源，整理事件輪廓、論點結構與可核實資訊的邊界。

文章的起點：打開開發者工具看 Cookie

減瓦在文中給出的第一組證據來自直接觀察。開啟瀏覽器開發者工具檢視 github.com 的 Cookie，可以發現僅有一條名為 _gh_session 的欄位，內容是 Rails 框架加密後的會話資料。Google 的網域下則排列著 SID、HSID、SSID、SAPISID 等多條 Cookie，Google 的隱私說明文件對此寫明，這些 Cookie 儲存的是經過數位簽章與加密的帳號 ID 及最近登入時間。文章進一步指出，Amazon 與 Netflix 的配置同樣屬於此類模式；Stack Overflow 看似特殊，使用的是 ASP.NET 的 Forms Authentication，但本質仍是服務端 Session。

這些觀察本身屬於任何人都可以重複驗證的範疇：打開開發者工具、查看 Cookie 名稱與內容編碼形式即可。文章的核心主張是，在這些主流網站的瀏覽器端登入態中，沒有一處使用 JWT。

文章同時交代了這個說法的傳播史。減瓦稱此一事實在技術社羣裡「被反覆提起，又反覆遺忘」，十年來 JWT 在教程、面試題與專案模板中的出現頻率極高，使部分後端開發者預設它就是現代認證的標準做法。

JWT 的適用場景與被放錯的位置

減瓦並未主張 JWT 一無是處，而是將問題定位為「被放錯了位置」。文章列舉 JWT 較適合的幾類場景：服務之間的內部呼叫，因為自包含的身分資訊可省去重複查詢，且閘道與服務網格生態對其支援成熟；需要離線校驗的邊緣節點，本地驗簽在該情境下合理；開放平臺中機器身分的自我證明，文中並以 GitHub 使用 JWT 處理此類事務為例。

文章援引 Stack Overflow 上一個被大量引用的回答，該回答的表述是：JWT 從來不是用來管理會話的，它是服務之間交換完整性保護訊息的工具。換句話說，JWT 是一份自帶簽章的憑證，適合在不受信任的邊界之間傳遞身分，但從頭到尾並非為瀏覽器會話而設計。

撤銷問題：文章眼中的硬傷

文章接著討論將 JWT 套用於瀏覽器登入場景後出現的問題，第一項是撤銷。使用者帳號被盜時，管理員若要立即將其踢下線，Session 方案只需服務端刪除該條會話紀錄；JWT 一旦簽出，在過期之前始終有效，服務端沒有官方手段使其作廢。

減瓦引用了兩個社羣訊源支撐此論點。其一是 Reddit 的 node 版塊上一段流傳甚廣的說法：不喜歡 JWT，因為它難以控制，帳號被入侵後沒有任何辦法讓那個 token 失效；若要失效只能維護黑名單，每個請求都查一遍黑名單，而一旦這麼做，JWT 標榜的無狀態特性便不復存在。其二是 Hacker News 上一條高讚評論的總結：JWT 的目標是無狀態，但只要需要可撤銷，它就不可能無狀態。

文章也交代了常見的折衷方案：縮短過期時間至五分鐘並搭配 refresh token 續期，把吊銷控制收在續期邊界上。此做法確實是若幹認證服務商的建議，但代價是引入整套雙 token 機制，且五分鐘時間窗內的攻擊仍無法攔截。文中引安全廠商 WorkOS 的分析，稱企業客戶最常見的第一條需求是「能不能立刻讓某個使用者下線」，而無狀態 JWT 恰好做不到這一點。

多數用法只是在模仿 Session

文章另一項論點來自 Reddit 的 PHP 協助版塊：絕大多數時候，人們用 JWT 只是在模仿 Session。減瓦以常見的實作流程說明：簽發一個只裝著 userId 的 token，每次請求收到後解析出來，再去資料庫查詢該使用者的詳細資料、判斷狀態與角色是否正常。整套流程下來，資料庫查詢一次沒少，額外開銷反而是簽名與驗簽。Session 同樣儲存 userId、同樣可以查庫，還能隨時銷毀，兩相比較之下 JWT 的版本更重。

還有一層更隱蔽的問題與時效性有關。JWT 的簽章只能保證 payload 未被竄改，不能保證 payload 中的資訊仍然成立。若一個 token 在簽發時寫著 role: admin，兩小時後該管理員權限被回收，token 中的 admin 依然有效直到過期。Session 方案則因權限判斷一律以服務端即時資料為準，不存在此落差。

安全性爭議與儲存位置的兩難

文章最後一段討論安全性。JWT 的 payload 僅經 Base64 編碼而非加密，將 token 拆開貼進任何解碼工具即可讀出內容。在瀏覽器場景中，這意味著所有使用者資訊對同源的 JavaScript 完全可見，儲存位置因此成為兩頭堵的選擇題。原文在此處中斷，後續論述未包含在可取得的內容之中。

訊源對照與可核實邊界

這篇文章的論證結構有一個明顯特徵：核心事實主張（主流網站 Cookie 內容）屬於可直接驗證的觀察，而評價性論點則依賴 Stack Overflow、Reddit、Hacker News 與 WorkOS 等多方引述。這些引述來源均為具名平臺上的公開發言，而非模糊歸因，其原始脈絡可回溯查證，但發言者多為匿名帳號，權威性各有差異。

需要說明的邊界有幾項。第一，文章討論範圍限定於瀏覽器端認證，行動 App 拿憑證呼叫 API 該用什麼格式，文中明確承認市場上存在多種選擇，大廠的答案也未必是 JWT，並強調該場景與瀏覽器會話是兩回事。第二，Cookie 內容的可讀性判讀涉及框架實作細節，一般使用者未必能從 Cookie 名稱直接斷定後端機制，文章的判讀基於對 Rails、Google 隱私說明與 ASP.NET 表單驗證的背景知識。第三，「主流網站一個都不用」是修辭性表述，其可核實範圍限於文章實際列舉的 GitHub、Google、Amazon、Netflix 與 Stack Overflow 等站，並非對全網的普查結論。

截至本文整理時，該篇掘金文章的後續討論與其他技術社羣的回應尚未有可交叉比對的完整紀錄。Session 與 JWT 在瀏覽器會話場景的取捨，在工程社羣中屬於長期存在的技術選型討論，此篇文章的貢獻在於將散落各處的觀察與引述彙整為一條完整論證，其各項主張均可依上述訊源逐條檢驗。