Hello，大家好，我是 Sunday。

昨天有同學(xué)找我吐槽：“上線第一天，系統(tǒng)突然崩了。用戶大量掉線、權(quán)限校驗(yàn)失效、后臺(tái)一堆 401……”

一查原因，是用了 JWT 做身份驗(yàn)證，但是！卻忽略了一個(gè)關(guān)鍵問題：Token 無法主動(dòng)失效。結(jié)果導(dǎo)致舊 Token 還在、用戶信息變更無效、登出機(jī)制形同虛設(shè)，系統(tǒng)很快就亂了。

這件事讓我意識(shí)到一個(gè)問題：

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

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

最老方案：Session

要說身份驗(yàn)證這事，Session 肯定是“資歷最老”的了。幾乎所有人剛?cè)腴T做登錄系統(tǒng)，第一個(gè)就是它。

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

1. 用戶輸入賬號(hào)密碼，點(diǎn)登錄；
2. 后端驗(yàn)證通過后，創(chuàng)建一條 Session 數(shù)據(jù)，生成唯一的 Session ID；
3. 后端通過 Set-Cookie 把這個(gè) Session ID 發(fā)給瀏覽器；
4. 瀏覽器自動(dòng)保存這個(gè) Cookie；
5. 以后每次請(qǐng)求，這個(gè) Cookie 自動(dòng)帶上，服務(wù)端就能識(shí)別出“哦，你是誰了”；
6. 用戶退出登錄？后端把這張紙條撕了，Session 就失效了。

簡(jiǎn)答來說就是： 用戶登錄后，服務(wù)端給你發(fā)個(gè) “小紙條”（Session ID），你每次來都帶著這張紙條，服務(wù)端一看，“哦，你是老李啊，進(jìn)吧吧。”。

根據(jù)以上流程，我們就可以發(fā)現(xiàn)：使用 Session 時(shí)，對(duì)前端幾乎 “無感知” 的，我們啥都不用操心：

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

尤其在公司內(nèi)網(wǎng)、傳統(tǒng)后臺(tái)項(xiàng)目中，香得很！

但是，為啥現(xiàn)在突然使用 Session 的就少了呢？

其實(shí)是因?yàn)榍昂蠖朔蛛x、微服務(wù)、移動(dòng)端……這些場(chǎng)景對(duì)它實(shí)在不太友好。

• 服務(wù)端要維護(hù) Session 狀態(tài)，不利于擴(kuò)展和分布式部署；
• Cookie 傳輸存在劫持風(fēng)險(xiǎn)，必須配合 HTTPS、安全配置一起上；
• 在配合上 微服務(wù)、微前端、跨域 就更加麻煩了

所以，在現(xiàn)代的復(fù)雜項(xiàng)目中，Session 就用的越來越少了。

用的最多的方案：JWT

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

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

先說一下 JWT 的基礎(chǔ)邏輯：

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

簡(jiǎn)單來說，就是：用戶登錄成功后，服務(wù)端不再存啥“Session”，而是直接簽發(fā)一個(gè) Token 給前端，你拿著這個(gè) Token 去訪問接口，服務(wù)端每次驗(yàn)證這個(gè) Token 來確認(rèn)你是誰。

這個(gè)流程，大部分同學(xué) 應(yīng)該熟悉，但是它的問題也很明顯：

• token 可能會(huì)長(zhǎng)期有效，在此期間一旦泄露就會(huì)很麻煩
• 無法讓其主動(dòng)失效，總不能維護(hù)一大堆黑名單吧

所以，JWT 確實(shí)不錯(cuò)，但是你需要做好對(duì)應(yīng)的優(yōu)化處理，比如：RefreshToken、黑名單 等等

只需要登錄一次：SSO 單點(diǎn)登錄

如果你做過企業(yè)項(xiàng)目、對(duì)接過公司統(tǒng)一認(rèn)證，那你一定聽過這個(gè)詞：SSO（Single Sign-On）——單點(diǎn)登錄

用戶只需要登錄一次，接下來訪問一堆系統(tǒng)都不用重復(fù)登錄了，一次認(rèn)證，全網(wǎng)通行。

咱們先來看下它的流程：

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

所以看上去你只登錄了一次，實(shí)際背后是多個(gè)系統(tǒng)和登錄中心在“套娃式”配合。

這樣做的優(yōu)勢(shì)是很明顯的：

• 一個(gè)賬號(hào)打通多個(gè)系統(tǒng)，少了好多登錄窗口
• 密碼只輸一次，不用記一堆
• 用戶登出一個(gè)系統(tǒng)，也能一并下線，統(tǒng)一管理更安全

所以就特別適合：OA、CRM、郵件系統(tǒng)、知識(shí)庫(kù)、審批流……這些系統(tǒng)分屬不同部門，但是屬于共一個(gè)公司的業(yè)務(wù)場(chǎng)景。

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

• 登錄中心一掛，所有系統(tǒng)全完蛋
• 配置復(fù)雜，調(diào)試起來更復(fù)雜
• 跨系統(tǒng)數(shù)據(jù)同步、權(quán)限管理稍微麻煩一些

登錄授權(quán)方案：OAuth 2.0

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

說對(duì)了，但是沒全對(duì)。

但如果你把 OAuth 理解成“用戶登錄協(xié)議”，那就大錯(cuò)特錯(cuò)了。OAuth 本質(zhì)上不是登錄協(xié)議，而是授權(quán)協(xié)議。

什么意思？

OAuth 的核心目標(biāo)只有一個(gè)，那就是：讓第三方應(yīng)用“在不拿到你密碼”的前提下，獲得你的一部分資源訪問權(quán)。

舉個(gè)例子：

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

網(wǎng)站能拿到這些信息，但是 它永遠(yuǎn)不知道你的微信密碼。這，就是 OAuth 的精髓：把權(quán)限，和賬號(hào)密碼分離。

整個(gè) OAuth 的流程略復(fù)雜，大致分為 5 步：

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

目前有很多系統(tǒng)，拿 OAuth 來做“登錄認(rèn)證”，但是遇到的坑也很多，比如：

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

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