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