JWT這東西做服務(wù)端開發(fā)的肯定不陌生。我印象很深的是剛工作那會兒第一次在項目代碼里看到一長串密密麻麻的token長得像亂碼夾著幾個英文單詞塞進請求頭里就能驗證身份。當時我盯著那串字符琢磨了半天服務(wù)端到底是怎么認出這個token的別人把它改一改服務(wù)端能不能發(fā)現(xiàn)后來花了幾天時間把JWT從結(jié)構(gòu)到原理整個捋了一遍才算是真正開了竅。如果你也在學JWT或者只是看著同事代碼里那行“Authorization: Bearer xxx”有點發(fā)懵這篇文章就是為你準備的。我按自己的學習路徑來寫先搞明白它到底解決什么問題再拆開看它長什么樣最后說清楚它為什么能保證安全。這一篇不急著寫代碼重點是建立完整的認知框架把“是什么”這層窗戶紙捅破。1. 先從最常見的場景說起登錄狀態(tài)到底是誰記住的1.1 HTTP協(xié)議天生“記性差”要理解JWT得先回到最原始的Web交互場景。用過抓包工具或者看過瀏覽器開發(fā)者工具的朋友都知道HTTP協(xié)議本身是一個“無狀態(tài)”的協(xié)議。什么叫無狀態(tài)就是你每次發(fā)請求服務(wù)器看待你都像看待一個陌生人。我發(fā)第一次請求說“我是A用戶”服務(wù)器處理完就把這件事忘了發(fā)第二次請求說“我是A用戶”服務(wù)器依舊不記得你是誰。這帶來的問題太明顯了一個電商網(wǎng)站你辛辛苦苦把商品加進了購物車刷新一下頁面購物車空了。你登錄了賬號點進個人中心結(jié)果它讓你重新登錄。沒有“狀態(tài)”這個概念所有需要記住用戶身份的功能全都玩不轉(zhuǎn)。所以從很早開始業(yè)界就在解決一個問題怎么讓HTTP請求“記住”用戶1.2 傳統(tǒng)方案基于Session的會話保持最常見的傳統(tǒng)方案是Session。我在很多項目里都接觸過這套機制流程大概是這樣的用戶提交用戶名密碼服務(wù)端驗證通過后在服務(wù)器內(nèi)存或者Redis里存一份會話數(shù)據(jù)生成一個會話IDSession ID。這個ID通過響應(yīng)頭里的Set-Cookie下發(fā)給瀏覽器。瀏覽器收到后在后續(xù)請求的Cookie字段里自動帶回這個ID。服務(wù)端拿到ID去內(nèi)存或Redis里一查發(fā)現(xiàn)這個會話有效就放行。在整個鏈路里真正的用戶數(shù)據(jù)存在服務(wù)端這邊客戶端手里只有一把“鑰匙”叫Session ID。鑰匙本身不包含任何用戶信息甚至沒有實際價值。這套機制在單體應(yīng)用時代非常好用。但我后來在幾個項目里逐步發(fā)現(xiàn)它有兩個讓人頭疼的地方第一服務(wù)端需要保存Session數(shù)據(jù)。用戶量一大這些會話數(shù)據(jù)占內(nèi)存也占存儲。更麻煩的是如果你部署了多臺服務(wù)器用戶在A服務(wù)器登錄了下次請求被負載均衡分到B服務(wù)器B服務(wù)器那沒有這個Session用戶就掉線了。解決辦法是搞Session共享把Session數(shù)據(jù)從各臺服務(wù)器挪出來放到統(tǒng)一的Redis集群里。這確實能解決問題但多了一層基礎(chǔ)設(shè)施鏈路也復(fù)雜了不少。第二Cookie在跨域場景下非常折騰?，F(xiàn)在的項目尤其前后端分離的項目前端頁面在A域名后端接口在B域名跨域請求里處理Cookie要額外配置域名、路徑、SameSite之類的屬性。你要是再做移動端AppApp里面根本就不是Cookie那套機制了還得手動管理Session ID的存儲。這些問題疊加在一起業(yè)內(nèi)自然開始找新的方案。JWT就是在這個背景下被越來越多人采用的一種替代思路。2. JWT到底是什么把三段結(jié)構(gòu)拆開揉碎2.1 先看一眼實物JWT全稱是JSON Web Token。按字面理解它是一個基于JSON格式的、用于網(wǎng)絡(luò)身份認證的令牌Token。我在項目里見過很多次實體它長這樣eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c猛一看就是三節(jié)亂碼中間用兩個英文句號..隔開所以JWT的整體結(jié)構(gòu)是“三段式兩分隔”。每一段分別叫Header頭部、Payload載荷、Signature簽名合在一起就是Header.Payload.Signature的格式。2.2 拆開看第一段Header把第一段解出來其實是個很簡單的JSON{ alg: HS256, typ: JWT }這里面有兩個字段。alg告訴服務(wù)端“我這個Token是用什么算法簽的名”比如HS256表示HMAC-SHA256RS256表示RSA-SHA256。typ說明這是一個JWT類型的令牌。這個JSON經(jīng)過Base64Url編碼就成了我們在JWT里看到的第一段字符串。注意這里只是編碼不是加密任何人都能把它解碼出來。2.3 再拆第二段Payload第二段Payload是JWT里攜帶信息的核心位置里面存放著所謂的“聲明”Claim。Claim就是“關(guān)于用戶和Token本身的一些陳述”。常見的標準聲明有這些subSubject這個Token的主題一般存用戶IDiatIssued At簽發(fā)時間時間戳格式expExpiration Time過期時間過了這個時間Token失效nbfNot Before在這之前不可用配合時間敏感的場景issIssuer簽發(fā)者標識是誰簽發(fā)的這個TokenaudAudience接收方標識Token是給誰用的jtiJWT IDToken的唯一標識除了標準聲明我們完全可以往Payload里塞自定義字段。比如想在前端頁面顯示用戶名就可以加一個username: 張三進去想?yún)^(qū)分用戶角色權(quán)限可以加一個role: admin。一個實際的Payload解碼出來長這樣{ sub: 1234567890, name: John Doe, iat: 1516239022, exp: 1516242622, role: admin }同樣這段JSON也是Base64Url編碼明文可讀。這里有個關(guān)鍵點我后面會反復(fù)強調(diào)Payload里的信息是任何人都能解的所以千萬別把密碼、身份證號、手機號這類敏感信息直接放進去。2.4 第三段是靈魂Signature前兩段編碼之后把結(jié)果和服務(wù)器保存的密鑰一起喂給簽名算法算出來結(jié)果就是第三段Signature。它的計算邏輯大致是signature HMACSHA256( base64urlEncode(header) . base64urlEncode(payload), secret )也就是說簽名是對“前兩段固定字符串”加上“密鑰”做一次哈希計算得到一串定長的輸出。這個Signature是JWT防篡改的關(guān)鍵。因為哈希計算有一個特性輸入的內(nèi)容哪怕只改一個字符輸出結(jié)果就會完全不一樣。而攻擊者手里沒有服務(wù)器那把密鑰他就算偽造了Header和Payload也算不出一個能通過服務(wù)端驗證的簽名。我經(jīng)常給朋友打的比方是JWT像一張蓋了防偽章的通行證。證件上的信息Payload誰都能看但章是專用章拿不到章就偽造不出同款通行證。服務(wù)端驗證的時候重新蓋一次章比對兩次章是否一致一致就說明這張通行證沒有被改過。2.5 為什么要用Base64Url而不是普通Base64這里有個小細節(jié)值得多說一嘴。網(wǎng)上很多文章會說JWT用Base64編碼這話不能說錯但不準確。JWT用的是Base64Url變種。普通Base64編碼的結(jié)果里可能含有、/以及末尾的填充字符。但和/在URL里是有特殊含義的——會被解析成空格/會干擾URL路徑分割。JWT經(jīng)常出現(xiàn)在URL參數(shù)、請求頭這些地方如果里面夾著這種特殊字符解析起來就容易出問題。Base64Url的解決辦法是把替換成-把/替換成_并且去掉末尾的填充。就這三處改動讓JWT可以安全地放進URL和Header里不用額外轉(zhuǎn)義。3. 完整走一遍從登錄到放行的流程3.1 登錄瞬間發(fā)生了什么光看結(jié)構(gòu)有點抽象我把整個流程串起來講一遍你就明白JWT是怎么在系統(tǒng)里流轉(zhuǎn)的了。假設(shè)現(xiàn)在有一個前后端分離的訂單系統(tǒng)。用戶在瀏覽器里輸入用戶名密碼點擊登錄。流程開始前端把用戶名密碼通過HTTPS POST到后端登錄接口后端驗證賬號密碼確認無誤后取出用戶ID把用戶ID、角色、過期時間這些信息組裝進Payload后端用密鑰對Header和Payload做簽名生成完整的JWT后端把JWT返回給前端登錄流程結(jié)束注意看這個過程中服務(wù)端并沒有在內(nèi)存或Redis里保存這個Token的任何信息。Token生成完服務(wù)端自己就不再“持有”它了。接下來就看客戶端怎么用。3.2 客戶端拿到Token之后怎么用前端收到這個JWT后通常會把它存起來存哪可以是localStorage、sessionStorage或者cookie各有各的坑我后面專門講。用戶接下來要訪問訂單列表了前端在發(fā)請求時會在HTTP請求頭里加上這樣一行Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c這個Bearer前綴是一個約定俗成的寫法表示后面這個字符串是一個承載令牌Bearer Token。也有一些系統(tǒng)直接用Cookie來攜帶JWT前端代碼不用管瀏覽器自動帶上。但顯式放在Authorization頭里是目前API對接最通用的方式。3.3 服務(wù)端怎么驗證一個JWT后端收到請求后不會去數(shù)據(jù)庫里查“這個Token是不是在有效會話列表里”它只需要做三件事把請求頭里的Token按.切分成三段拿到Header、Payload、Signature用同樣的算法Header里的alg字段會告訴它和服務(wù)器密鑰對前兩段重新計算一次簽名把算出來的簽名和客戶端傳來的簽名比對一致則驗證通過驗證通過后服務(wù)端還會順手檢查Payload里的exp字段如果當前時間已經(jīng)超過過期時間就直接拒絕。通過之后服務(wù)端就直接信任Payload里攜帶的用戶ID、角色信息用它完成后續(xù)的業(yè)務(wù)邏輯。關(guān)鍵區(qū)別在于驗證不依賴于查詢“存儲”。這就是它和Session最大的分水嶺。3.4 無狀態(tài)到底意味著什么Session方案里服務(wù)端拿到Session ID后必須“查”一下自己的存儲確認會話存在才能放行這個動作叫“有狀態(tài)認證”。JWT不需要這個查詢動作——Token本身就包含了所有驗證所需的信息服務(wù)端拿著密鑰一算就知道Token真假。你只要算一遍簽名驗一下時間結(jié)果就在眼前。這就是常說的“無狀態(tài)”。無狀態(tài)帶來的直接好處是任意一臺服務(wù)器都能獨立驗證Token服務(wù)器之間不需要共享任何會話數(shù)據(jù)。應(yīng)用需要擴容時隨便加機器就行不用考慮Session同步的問題。微服務(wù)架構(gòu)里各個服務(wù)各自驗簽認證邏輯從業(yè)務(wù)代碼里剝離開來這是JWT在分布式環(huán)境下越來越流行的核心原因。4. JWT的優(yōu)點和代價都得看清楚4.1 那些讓人舒服的地方我在項目里實際對比過Session和JWTJWT的優(yōu)勢相當明顯?？缬蚝彤悩?gòu)場景友好。Session依賴CookieCookies有跨域限制設(shè)置起來又得動域名又得配屬性。JWT放在Authorization頭里不受瀏覽器同源策略約束前后端分離、多端共用一套API都能很自然地對接受。移動端和原生應(yīng)用友好。App里面做Session要手動處理會話ID的保存和傳遞JWT相比之下簡單得多拿到就存請求就帶沒有任何額外機制。天然支持水平擴展。前面說了服務(wù)端不存狀態(tài)擴容時零負擔。這個優(yōu)勢在訪問量上來之后會體現(xiàn)得非常明顯。信息自包含。Payload里帶用戶ID和角色微服務(wù)拿到Token就能直接知道用戶是誰、權(quán)限多大不需要再回查統(tǒng)一的會話服務(wù)。在一個訂單服務(wù)、用戶服務(wù)、支付服務(wù)各自獨立的架構(gòu)里這種體驗簡直順滑。4.2 那些必須付出的代價JWT也不是銀彈我自己使用過程中踩過的坑也大多在這些方面。Token無法在失效前主動作廢。這是JWT最讓人糾結(jié)的點。Session方案里管理員把會話從Redis里刪掉用戶立刻失效。JWT呢只要Token沒過期就算用戶改了密碼就算管理員把用戶封了服務(wù)端驗簽仍然是“通過”的除非服務(wù)端額外維護一個黑名單那又回到“有狀態(tài)”的老路上了。Token體積偏大。JWT的Payload里帶了用戶信息加簽名后整體比一個Session ID大很多。每次請求都要在Header里帶一個幾KB的字符串雖然有Gzip壓縮能緩解但在移動端網(wǎng)絡(luò)環(huán)境下這開銷是實打?qū)嵉摹ｏL險面前置到客戶端。Session方案里客戶端只持有一個隨機的ID就算被偷了ID本身沒暴露什么信息。JWT直接在客戶端存了一份可解碼的用戶信息。所以JWT對存Storage的安全要求更高XSS攻擊的風險要專門防范。依賴簽名算法和密鑰管理。服務(wù)端密鑰一旦泄露所有Token都能被偽造。而alg字段如果服務(wù)端沒做校驗還有算法混淆攻擊的風險。這些在后面安全部分細講。5. 新手最容易踩的幾個坑5.1 把敏感信息直接塞進Payload這是我最想強調(diào)的一個坑。JWT的Payload是Base64Url編碼不是加密。我見過有同學把用戶密碼、手機號、身份證號直接塞進Payload理由是“項目里需要用到”完全沒有意識到這等于把敏感信息明文送到了客戶端手里。正確做法是Payload里只放非敏感的用戶標識比如用戶ID、角色、過期時間這種信息。真正敏感的數(shù)據(jù)還是得到服務(wù)端按ID去查。一定記住一句話JWT的作用是“驗證”和“標識”不是“加密存儲”。所有寫進Payload的內(nèi)容默認都是半公開的。5.2 登出接口明明調(diào)了Token還是能用這是JWT新手幾乎必踩的坑。前端把Token從本地刪掉請求確實帶不過去了但這只是“客戶端這邊不再發(fā)送”而已。如果攻擊者提前把這個Token抄走了他照樣可以用這個Token繼續(xù)訪問接口。服務(wù)端層面要做真正的“登出”辦法有幾種一是維護一個Token黑名單登出時把Token的jti或原始字符串加進黑名單過期時間到了才移除二是縮短Token有效期配合Refresh Token機制輪換三是部署時用網(wǎng)關(guān)層統(tǒng)一攔截。各有利弊但核心思想要明確單靠前端刪Token不叫真正的登出。5.3 Token有效期設(shè)置不合理我見過兩種極端一種是把exp設(shè)成一小時結(jié)果用戶用著用著突然掉線體驗很差另一種是一不做二不休把過期時間設(shè)成一年甚至干脆不設(shè)expToken永久有效出安全問題根本沒法收場。后來我實踐中常用的模式是雙Token方案一個短期Token比如15分鐘或1小時負責正常業(yè)務(wù)訪問一個長期Refresh Token比如7天或30天負責快過期時申請新的短期Token。Refresh Token走單獨的接口只在需要續(xù)期的時候攜帶被攻擊的窗口就小很多。5.4 簽名密鑰和算法校驗HS256和RS256兩種算法都有團隊在用但它們的密鑰體系不一樣。HS256是對稱加密簽名和驗證用同一個密鑰所以密鑰必須妥善保管在服務(wù)端絕不能下發(fā)到前端。RS256是非對稱加密簽名用私鑰驗證用公鑰公鑰可以公開。正是因為Header里的alg字段是客戶端可以改的服務(wù)端如果把算法寫死只信任自己配置的那一種就不會出問題。如果動態(tài)讀取alg來驗證攻擊者可以把alg改成none或者HS256來混淆算法。這類攻擊在安全圈真實發(fā)生過服務(wù)端務(wù)必白名單校驗算法。5.5 Token存哪里更安全localStorage、sessionStorage還是Cookie這個問題每次都能吵一輪。我的個人實踐經(jīng)驗是localStorage簡單但容易被XSS腳本讀取Token一旦被拿走就是致命的Cookie配合HttpOnly屬性腳本代碼讀不到防XSS效果好但要留意CSRF攻擊如果項目XSS面控制得不好用HttpOnly Cookie更放心穩(wěn)妥的做法是短期Token存內(nèi)存或比較安全的地方Refresh Token放HttpOnly Cookie盡量減小被竊取的暴露面。具體取舍要看團隊對安全風險的接受程度。6. 一份不折騰的學習路線建議6.1 最快的方式跑通一個最小示例學這個東西光看不練真的記不住。我的建議是直接寫一個最小的Demo感受一下“簽出來、驗回去”的過程。用Node.js的jsonwebtoken庫幾分鐘就能跑通。const jwt require(jsonwebtoken); // 模擬Payload const payload { sub: 10001, name: 某開發(fā)者, role: admin }; const secret my-secret-key; // 簽發(fā)默認使用HS256算法 const token jwt.sign(payload, secret, { expiresIn: 2h }); console.log(生成的JWT:); console.log(token); // 驗證 try { const decoded jwt.verify(token, secret); console.log(\n驗證通過解析結(jié)果:); console.log(decoded); } catch (err) { console.log(\n驗證失敗:, err.message); }你把它save成demo.jsnpm install jsonwebtoken之后node demo.js跑起來控制臺會打印出完整的JWT和驗證后的對象。把Token復(fù)制到 jwt.io 上解碼看看直觀感受一下Payload的信息是完全可見的。這一步能讓你把抽象的結(jié)構(gòu)和實際字符串對上號。6.2 再動手寫一段“偽造”Token跑通簽發(fā)和驗證之后我強烈建議你做一個實驗把生成的Token隨便改一個字符比如把Payload里的某個字母換掉再放進驗證代碼里跑一次。你會發(fā)現(xiàn)jwt.verify立刻拋錯提示簽名不匹配。這個“破壞性”實驗做完你對“簽名防篡改”的記憶會非常牢固。6.3 最后還想多說一句學了JWT之后別急著把項目里的Session全部替換掉。兩者各有所長Session在需要“立即失效”場景下有不可替代的優(yōu)勢JWT在分布式、多端場景里更方便。你現(xiàn)在要做的不是站隊而是理解它們各自解決什么問題。以后真正面對項目選型時腦子里能有個清晰的判斷框架這比多背幾個名詞有用得多。我自己在好幾次項目里從Session切到JWT感受最深的不是它“更安全”而是它“更簡單”——它讓每個服務(wù)都能獨立驗證請求把認證這件事從業(yè)務(wù)代碼里解耦了出來。但每一次當有人問我“JWT能不能主動注銷”我還是會停下來想兩秒然后告訴他這就是無狀態(tài)要付出的代價。把這個問題想明白了你就真正理解了JWT。