昨天有同學找我吐槽：“上線第一天，系統突然崩了。用戶大量掉線、權限校驗失效、后臺一堆 401……”

一查原因，是用了 JWT 做身份驗證，但是！卻忽略了一個關鍵問題：Token 無法主動失效。結果導致舊 Token 還在、用戶信息變更無效、登出機制形同虛設，系統很快就亂了。

這件事讓我意識到一個問題：

很多人雖然“用過” JWT、Session、SSO、OAuth，但其實并沒有真正理解它們的本質區別。

今天這篇文章，就帶你梳理一下這 4 種前端常見的身份驗證方式，不光要知道怎么用，還得知道他們背后的原理都有啥！

最老方案：Session

要說身份驗證這事，Session 肯定是“資歷最老”的了。幾乎所有人剛入門做登錄系統，第一個就是它。

那么它是怎么工作呢的？完整的流程，大致可以分為 6 步：

1. 用戶輸入賬號密碼，點登錄；
2. 后端驗證通過后，創建一條 Session 數據，生成唯一的 Session ID；
3. 后端通過 Set-Cookie 把這個 Session ID 發給瀏覽器；
4. 瀏覽器自動保存這個 Cookie；
5. 以后每次請求，這個 Cookie 自動帶上，服務端就能識別出“哦，你是誰了”；
6. 用戶退出登錄？后端把這張紙條撕了，Session 就失效了。

簡答來說就是： 用戶登錄后，服務端給你發個 “小紙條”（Session ID），你每次來都帶著這張紙條，服務端一看，“哦，你是老李啊，進吧吧。”。

根據以上流程，我們就可以發現：使用 Session 時，對前端幾乎 “無感知” 的，我們啥都不用操心：

• 瀏覽器自動幫我們帶 Cookie；
• 登出只要后端把 Session 刪了就行；
• 登錄態是服務器說了算，能立刻失效，不留后患。

尤其在公司內網、傳統后臺項目中，香得很！

但是，為啥現在突然使用 Session 的就少了呢？

其實是因為前后端分離、微服務、移動端……這些場景對它實在不太友好。

• 服務端要維護 Session 狀態，不利于擴展和分布式部署；
• Cookie 傳輸存在劫持風險，必須配合 HTTPS、安全配置一起上；
• 在配合上 微服務、微前端、跨域 就更加麻煩了

所以，在現代的復雜項目中，Session 就用的越來越少了。

用的最多的方案：JWT

講真，現在要是你說沒用過 JWT（Token），可能都不好意思說自己搞過前端分離。

但也正是這個“火”，讓很多人以為它非常好用，從而忽略了它的一些問題，比如：文章最初上線第一天就掛了的同學

先說一下 JWT 的基礎邏輯：

1. 用戶登錄，提交用戶名密碼；
2. 后端驗證通過后，生成一個帶有用戶信息的 JWT（通常是用戶 ID、權限、過期時間）；
3. 把這個 JWT 返回給前端；
4. 前端把它存到 localStorage 或者 cookie（自己看情況）；
5. 后續請求時，前端主動在 Authorization 頭里帶上這個 Token；
6. 后端收到請求后解析 Token，驗證合法性，然后決定要不要放行。

簡單來說，就是：用戶登錄成功后，服務端不再存啥“Session”，而是直接簽發一個 Token 給前端，你拿著這個 Token 去訪問接口，服務端每次驗證這個 Token 來確認你是誰。

這個流程，大部分同學 應該熟悉，但是它的問題也很明顯：

• token 可能會長期有效，在此期間一旦泄露就會很麻煩
• 無法讓其主動失效，總不能維護一大堆黑名單吧

所以，JWT 確實不錯，但是你需要做好對應的優化處理，比如：RefreshToken、黑名單 等等

只需要登錄一次：SSO 單點登錄

如果你做過企業項目、對接過公司統一認證，那你一定聽過這個詞：SSO（Single Sign-On）——單點登錄

用戶只需要登錄一次，接下來訪問一堆系統都不用重復登錄了，一次認證，全網通行。

咱們先來看下它的流程：

1. 用戶訪問系統 A，系統發現你沒登錄，直接把你重定向到「登錄中心」；
2. 登錄中心讓你輸入賬號密碼；
3. 登錄成功后，它發一個「身份令牌」；
4. 然后再把你重定向回系統 A，并帶上令牌；
5. 系統 A 拿這個令牌去登錄中心驗證——你是誰、能不能進；
6. 驗證通過，OK，放行；
7. 接下來你再去系統 B、C……他們也會讓你先去登錄中心“刷個臉”，但你已經登錄過了，直接放行。

所以看上去你只登錄了一次，實際背后是多個系統和登錄中心在“套娃式”配合。

這樣做的優勢是很明顯的：

• 一個賬號打通多個系統，少了好多登錄窗口
• 密碼只輸一次，不用記一堆
• 用戶登出一個系統，也能一并下線，統一管理更安全

所以就特別適合：OA、CRM、郵件系統、知識庫、審批流……這些系統分屬不同部門，但是屬于共一個公司的業務場景。

但是它的問題也是存在的，比如：

• 登錄中心一掛，所有系統全完蛋
• 配置復雜，調試起來更復雜
• 跨系統數據同步、權限管理稍微麻煩一些

登錄授權方案：OAuth 2.0

說起 OAuth 2.0，很多人第一反應是：“哦，那不就是微信掃碼登錄、GitHub 登錄那些東西嗎？”

說對了，但是沒全對。

但如果你把 OAuth 理解成“用戶登錄協議”，那就大錯特錯了。OAuth 本質上不是登錄協議，而是授權協議。

什么意思？

OAuth 的核心目標只有一個，那就是：讓第三方應用“在不拿到你密碼”的前提下，獲得你的一部分資源訪問權。

舉個例子：

你用第三方網站（比如：石墨文檔）綁定微信登錄，授權它“獲取你的微信頭像和昵稱”。

網站能拿到這些信息，但是 它永遠不知道你的微信密碼。這，就是 OAuth 的精髓：把權限，和賬號密碼分離。

整個 OAuth 的流程略復雜，大致分為 5 步：

1. 第三方應用（比如石墨）發起登錄請求，把你重定向到微信；
2. 你在微信頁面確認授權（允許它獲取昵稱、頭像）；
3. 微信授權完后，發回一個“授權碼”給石墨；
4. 石墨再拿這個碼去微信那邊換“訪問令牌（Access Token）”；
5. 有了 Token，就可以去微信獲取你的信息了。

目前有很多系統，拿 OAuth 來做“登錄認證”，但是遇到的坑也很多，比如：

• 沒搞清楚用戶信息怎么拿；
• Token 過期機制處理不好；
• 把 AccessToken 存 localStorage，結果被偷走直接暴露資源；

特別是你自己在搞“掃碼登錄”這一套，想用 OAuth 模仿微信，沒搞明白授權碼和 Token 的生命周期，那系統大概率會掛。