用了 JWT，上線第一天，系統就掛了......
Hello，大家好，我是 Sunday。
昨天有同學找我吐槽：“上線第一天，系統突然崩了。用戶大量掉線、權限校驗失效、后臺一堆 401……”
一查原因，是用了 JWT 做身份驗證，但是！卻忽略了一個關鍵問題：Token 無法主動失效。結果導致舊 Token 還在、用戶信息變更無效、登出機制形同虛設，系統很快就亂了。
這件事讓我意識到一個問題：
很多人雖然“用過” JWT、Session、SSO、OAuth，但其實并沒有真正理解它們的本質區別。
今天這篇文章，就帶你梳理一下這 4 種前端常見的身份驗證方式，不光要知道怎么用，還得知道他們背后的原理都有啥！
最老方案：Session
要說身份驗證這事，Session 肯定是“資歷最老”的了。幾乎所有人剛入門做登錄系統，第一個就是它。
那么它是怎么工作呢的？完整的流程，大致可以分為 6 步：
- 用戶輸入賬號密碼，點登錄；
- 后端驗證通過后，創建一條 Session 數據，生成唯一的 Session ID；
- 后端通過
Set-Cookie把這個 Session ID 發給瀏覽器； - 瀏覽器自動保存這個 Cookie；
- 以后每次請求，這個 Cookie 自動帶上，服務端就能識別出“哦，你是誰了”；
- 用戶退出登錄？后端把這張紙條撕了，Session 就失效了。
簡答來說就是： 用戶登錄后，服務端給你發個 “小紙條”（Session ID），你每次來都帶著這張紙條，服務端一看，“哦，你是老李啊，進吧吧。”。
根據以上流程，我們就可以發現：使用 Session 時，對前端幾乎 “無感知” 的，我們啥都不用操心：
- 瀏覽器自動幫我們帶 Cookie；
- 登出只要后端把 Session 刪了就行；
- 登錄態是服務器說了算，能立刻失效，不留后患。
尤其在公司內網、傳統后臺項目中，香得很！
但是，為啥現在突然使用 Session 的就少了呢？
其實是因為前后端分離、微服務、移動端……這些場景對它實在不太友好。
- 服務端要維護 Session 狀態，不利于擴展和分布式部署；
- Cookie 傳輸存在劫持風險，必須配合 HTTPS、安全配置一起上；
- 在配合上 微服務、微前端、跨域 就更加麻煩了
所以，在現代的復雜項目中，Session 就用的越來越少了。
用的最多的方案：JWT
講真，現在要是你說沒用過 JWT（Token），可能都不好意思說自己搞過前端分離。
但也正是這個“火”，讓很多人以為它非常好用，從而忽略了它的一些問題，比如：文章最初上線第一天就掛了的同學
先說一下 JWT 的基礎邏輯：
- 用戶登錄，提交用戶名密碼；
- 后端驗證通過后，生成一個帶有用戶信息的 JWT（通常是用戶 ID、權限、過期時間）；
- 把這個 JWT 返回給前端；
- 前端把它存到
localStorage或者cookie（自己看情況）； - 后續請求時，前端主動在
Authorization頭里帶上這個 Token； - 后端收到請求后解析 Token，驗證合法性，然后決定要不要放行。
簡單來說，就是：用戶登錄成功后，服務端不再存啥“Session”，而是直接簽發一個 Token 給前端，你拿著這個 Token 去訪問接口，服務端每次驗證這個 Token 來確認你是誰。
這個流程，大部分同學 應該熟悉，但是它的問題也很明顯：
- token 可能會長期有效，在此期間一旦泄露就會很麻煩
- 無法讓其主動失效，總不能維護一大堆黑名單吧
所以，JWT 確實不錯，但是你需要做好對應的優化處理，比如：RefreshToken、黑名單 等等
只需要登錄一次：SSO 單點登錄
如果你做過企業項目、對接過公司統一認證，那你一定聽過這個詞：SSO（Single Sign-On）——單點登錄
用戶只需要登錄一次，接下來訪問一堆系統都不用重復登錄了，一次認證，全網通行。
咱們先來看下它的流程：
- 用戶訪問系統 A，系統發現你沒登錄，直接把你重定向到「登錄中心」；
- 登錄中心讓你輸入賬號密碼；
- 登錄成功后，它發一個「身份令牌」；
- 然后再把你重定向回系統 A，并帶上令牌；
- 系統 A 拿這個令牌去登錄中心驗證——你是誰、能不能進；
- 驗證通過，OK，放行；
- 接下來你再去系統 B、C……他們也會讓你先去登錄中心“刷個臉”，但你已經登錄過了，直接放行。
所以看上去你只登錄了一次，實際背后是多個系統和登錄中心在“套娃式”配合。
這樣做的優勢是很明顯的：
- 一個賬號打通多個系統，少了好多登錄窗口
- 密碼只輸一次，不用記一堆
- 用戶登出一個系統，也能一并下線，統一管理更安全
所以就特別適合：OA、CRM、郵件系統、知識庫、審批流……這些系統分屬不同部門，但是屬于共一個公司的業務場景。
但是它的問題也是存在的，比如：
- 登錄中心一掛，所有系統全完蛋
- 配置復雜，調試起來更復雜
- 跨系統數據同步、權限管理稍微麻煩一些
登錄授權方案：OAuth 2.0
說起 OAuth 2.0，很多人第一反應是：“哦，那不就是微信掃碼登錄、GitHub 登錄那些東西嗎？”
說對了，但是沒全對。
但如果你把 OAuth 理解成“用戶登錄協議”，那就大錯特錯了。OAuth 本質上不是登錄協議，而是授權協議。
什么意思？
OAuth 的核心目標只有一個，那就是：讓第三方應用“在不拿到你密碼”的前提下，獲得你的一部分資源訪問權。
舉個例子：
你用第三方網站（比如：石墨文檔）綁定微信登錄，授權它“獲取你的微信頭像和昵稱”。
網站能拿到這些信息，但是 它永遠不知道你的微信密碼。這，就是 OAuth 的精髓：把權限，和賬號密碼分離。
整個 OAuth 的流程略復雜，大致分為 5 步：
- 第三方應用（比如石墨）發起登錄請求，把你重定向到微信；
- 你在微信頁面確認授權（允許它獲取昵稱、頭像）；
- 微信授權完后，發回一個“授權碼”給石墨；
- 石墨再拿這個碼去微信那邊換“訪問令牌（Access Token）”；
- 有了 Token，就可以去微信獲取你的信息了。
目前有很多系統，拿 OAuth 來做“登錄認證”，但是遇到的坑也很多，比如：
- 沒搞清楚用戶信息怎么拿；
- Token 過期機制處理不好；
- 把 AccessToken 存 localStorage，結果被偷走直接暴露資源；
特別是你自己在搞“掃碼登錄”這一套，想用 OAuth 模仿微信，沒搞明白授權碼和 Token 的生命周期，那系統大概率會掛。
