1. 為什么JWT安全值得單獨(dú)寫一篇文章1.1 先看兩個真實(shí)事故我先把話說在前頭JWTJSON Web Token這幾年幾乎成了后端鑒權(quán)的默認(rèn)答案Spring Security整合JWT、SPA項(xiàng)目里用token做登錄態(tài)、網(wǎng)關(guān)層統(tǒng)一校驗(yàn)身份到處都是它的身影。但正因?yàn)橛玫脧V被打穿的案例也特別多。2023年有個讓我印象深刻的漏洞某開源注冊配置中心組件對應(yīng)CNVD-2023-17316存在默認(rèn)密鑰身份認(rèn)證繞過問題攻擊者拿著內(nèi)置的JWT默認(rèn)簽名密鑰直接偽造身份標(biāo)識連交互都不用交互就繞過了管理端的認(rèn)證。這類問題不是個例很多團(tuán)隊(duì)把JWT當(dāng)成了用了就安全的銀彈結(jié)果密鑰明文寫在代碼里、算法不校驗(yàn)、過期時間設(shè)成一年等于把門鎖掛在紙糊的墻上。另一個高頻事故是算法混淆攻擊。攻擊者把token的header里alg字段改成none或者把RS256改成HS256不少老代碼沒做算法白名單校驗(yàn)直接照著header里的算法去驗(yàn)簽于是攻擊者隨便編一個token就通過了校驗(yàn)。這兩種事故告訴我們一件事JWT本身只是個協(xié)議規(guī)范安全問題幾乎都出在使用環(huán)節(jié)和實(shí)現(xiàn)細(xì)節(jié)上。這文章我就打算從結(jié)構(gòu)、發(fā)包格式、常見漏洞、落地實(shí)現(xiàn)、問題排查五個維度展開把JWT從簽發(fā)到驗(yàn)簽再到續(xù)簽的每個環(huán)節(jié)都過一遍。內(nèi)容偏實(shí)戰(zhàn)后端開發(fā)、安全測試、架構(gòu)評審的同事都可以直接參考。1.2 JWT的安全邊界到底在哪先說一個很多人搞錯的認(rèn)知JWT不等于加密。JWT的payload默認(rèn)只是做了Base64URL編碼任何人拿到token都能解碼看到里面的內(nèi)容。簽名只是保證內(nèi)容沒被篡改并不能保證內(nèi)容不被偷看。所以安全邊界可以壓縮成三句話簽名防篡改HTTPS防竊聽密鑰保真實(shí)任何一環(huán)松動整個鑒權(quán)鏈條就會塌。舉個例子你就算簽名算法選得再強(qiáng)如果密鑰是個寫在代碼里的硬編碼字符串secret123攻擊者只要能拿到源碼或者猜到密鑰就能自己簽一個合法token想冒充誰就冒充誰。反過來如果你的payload里放了用戶的手機(jī)號、身份證就算簽名沒被破解token在傳輸過程中被日志記錄、被瀏覽器插件截獲解碼出來就是明文泄露。還有一個本質(zhì)區(qū)別需要理解傳統(tǒng)Session方案里服務(wù)端session是存在內(nèi)存或Redis里的服務(wù)端可以隨時刪除一個session讓用戶強(qiáng)制下線。但JWT是無狀態(tài)的token一旦簽發(fā)出去在它過期之前服務(wù)端沒有任何辦法主動讓它失效。這個特性讓JWT天然適合分布式水平擴(kuò)展不需要共享session存儲但也意味著提前吊銷強(qiáng)制下線踢人這些操作全都得靠額外手段彌補(bǔ)。你設(shè)計(jì)JWT方案的時候必須帶著這個認(rèn)知去做權(quán)衡。2. JWT結(jié)構(gòu)與發(fā)包格式拆解2.1 三段結(jié)構(gòu)的逐字節(jié)拆解JWT長什么樣先看一個真實(shí)tokeneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c它由兩段點(diǎn)號分成三個部分Header、Payload、Signature。三個部分各自獨(dú)立做Base64URL編碼然后拼接成header.payload.signature。Header和Payload都是JSON對象。Header里常見的字段是alg簽名算法和typ類型通常固定為JWT。Payload里是各種聲明claims比如sub主題、exp過期時間、iat簽發(fā)時間、aud受眾、iss簽發(fā)者。Signature則是用Header里聲明的算法把前兩段加上密鑰一起算出來的簽名結(jié)果。這里有一個編碼細(xì)節(jié)必須強(qiáng)調(diào)JWT用的是Base64URL不是標(biāo)準(zhǔn)Base64。標(biāo)準(zhǔn)Base64的字符集里有和/放到URL里會被當(dāng)成空格和路徑分隔符而且標(biāo)準(zhǔn)Base64還有填充字符。Base64URL把換成-把/換成_并且去掉末尾的填充。你手寫解析的時候如果用了標(biāo)準(zhǔn)Base64去解碼要么報錯要么解出亂碼。Python和Java的標(biāo)準(zhǔn)庫里都有專門的Base64URL編碼器別自己拼字符串去解。簽名的生成過程以HS256為例就四步把Header用Base64URL編碼把Payload用Base64URL編碼用HMAC-SHA256(base64url(header) . base64url(payload), secret)算出摘要把摘要再做一次Base64URL編碼得到Signature驗(yàn)簽時就是把前兩段重新拼起來再用密鑰算一遍簽名和token里的第三段比對。比對的時候要用常量時間比較函數(shù)防止時序攻擊這點(diǎn)標(biāo)準(zhǔn)庫基本都處理了但你自己寫演示代碼的時候要注意別用普通字符串equals。2.2 關(guān)鍵聲明字段與常見的危險配置Payload里的聲明字段有的非常安全有的埋著雷。我按重要性逐個說。alg這是攻擊者最常動的字段。服務(wù)端解析時必須把它當(dāng)不可信輸入絕不能直接信任它然后去執(zhí)行對應(yīng)的驗(yàn)簽邏輯。安全做法是代碼里寫死算法白名單比如只允許RS256或者只允許HS256解析時先檢查這個值。kidKey ID用于告訴服務(wù)端用哪把密鑰來驗(yàn)簽。這字段看起來人畜無害但如果服務(wù)端把它拼進(jìn)文件路徑或者SQL查詢里就成了注入點(diǎn)。后面講漏洞的時候我會專門展開。exp過期時間Unix時間戳秒。簽發(fā)的時候必須設(shè)置驗(yàn)簽的時候必須校驗(yàn)。有些團(tuán)隊(duì)圖省事不設(shè)過期時間結(jié)果token永久有效一個被泄露的token就能用到天荒地老。nbf生效時間表示在這個時間之前token無效。分布式環(huán)境下各個服務(wù)時鐘不一定完全一致如果設(shè)置了nbf建議留出一兩分鐘的時鐘偏移容忍量否則會出現(xiàn)客戶端拿到的token還沒生效的詭異問題。iat簽發(fā)時間主要用于審計(jì)和計(jì)算剩余有效期。jtiJWT ID唯一標(biāo)識。這個字段在實(shí)現(xiàn)token吊銷和防重放時特別有用服務(wù)端可以把已使用的jti放到Redis里做短期緩存有效期內(nèi)同一個token重復(fù)使用就拒絕。sub/iss/aud分別表示主體、簽發(fā)者、受眾。多服務(wù)場景下強(qiáng)烈建議校驗(yàn)iss和aud防止一個服務(wù)簽發(fā)的token被拿到另一個服務(wù)里冒用。2.3 一個Token在請求里到底怎么發(fā)JWT的HTTP標(biāo)準(zhǔn)攜帶方式是放在Authorization請求頭里格式是Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Bearer后面跟一個空格然后是完整的token字符串。為什么主流方案都推薦放Header而不是放URL參數(shù)因?yàn)閁RL會進(jìn)Web服務(wù)器日志、代理日志、瀏覽器歷史記錄token一旦進(jìn)了日志等于把鑰匙丟在了大街上。Header相對干凈雖然也有反向代理記錄Header的情況但可控性高得多。實(shí)際項(xiàng)目里也有用Cookie存token的尤其是SPA應(yīng)用配合HttpOnlyCookie可以降低XSS竊取token的風(fēng)險。但Cookie方案必須面對CSRF的困擾。如果token在AuthorizationHeader里CSRF攻擊者沒有跨域讀取Header的能力天然免疫這類問題如果token在Cookie里瀏覽器會自動帶上攻擊者可以誘導(dǎo)用戶發(fā)起請求來借用用戶身份就必須額外加CSRF Token或者SameSite策略。我見過不少項(xiàng)目在Cookie模式下忘記加CSRF防護(hù)這是典型的權(quán)衡漏洞。再補(bǔ)充一個細(xì)節(jié)JWT本身不是只有Header一種傳輸方式。WebSocket握手階段通過Sec-WebSocket-Protocol子協(xié)議傳token、gRPC里通過metadata傳authorization也是常見做法。但不管怎么傳核心原則只有一條token只走安全通道只存在受控客戶端。順帶說一下安全測試人員最關(guān)心的發(fā)包格式。如果你在Burp Suite里測試拿到一個token后想自己改payload再發(fā)包可以直接把Header和Payload解出來修改后重新Base64URL編碼但別急著改簽名——除非你拿到了密鑰否則改了簽名肯定驗(yàn)不過。如果只是想觀察服務(wù)端對token格式錯誤的反應(yīng)可以把簽名部分隨便改幾個字符看它返回401還是500這能幫你判斷異常處理是否規(guī)范。3. 常見JWT漏洞與攻擊手法復(fù)現(xiàn)3.1 算法混淆攻擊從algnone到公鑰當(dāng)密鑰算法混淆是JWT最經(jīng)典的一類漏洞攻擊思路簡單粗暴篡改Header里的alg字段讓服務(wù)端用攻擊者可控的方式去驗(yàn)簽。第一種是alg: none。有些老版本庫在實(shí)現(xiàn)時看到alg為none就直接跳過簽名校驗(yàn)token第三段甚至可以不存在。攻擊者把a(bǔ)lg改成nonepayload改成自己要的角色比如{sub:admin,role:administrator,exp:9999999999}然后去掉簽名段構(gòu)造出header.payload.這樣的畸形token。如果服務(wù)端沒有做算法白名單直接信任alg字段管理員身份就這么被偽造出來了。第二種是RS256到HS256的混淆。RS256是RSA非對稱簽名用私鑰簽、公鑰驗(yàn)HS256是對稱HMAC簽發(fā)和驗(yàn)簽用同一個密鑰。問題在于很多服務(wù)把RSA公鑰公開比如放在JWKS端點(diǎn)驗(yàn)簽時讀取token里的alg。如果攻擊者把a(bǔ)lg改成HS256有些實(shí)現(xiàn)就會拿公鑰的字節(jié)內(nèi)容當(dāng)作HMAC的密鑰來做驗(yàn)簽。而公鑰是公開的攻擊者拿到公鑰后用HS256算法、以公鑰內(nèi)容為密鑰就能給自己簽發(fā)合法token。修復(fù)方法還是那句服務(wù)端驗(yàn)簽算法必須寫死白名單不允許客戶端指定。實(shí)測中這種攻擊在自研驗(yàn)簽邏輯的代碼里特別常見。標(biāo)準(zhǔn)庫一般會在解析時暴露parserBuilder().setAlgorithmWhitelist(...)之類的接口你只要跳過不配就等于把算法選擇權(quán)交給了攻擊者。3.2 kid參數(shù)注入當(dāng)Key ID變成任意文件讀取kid字段的作用是告訴服務(wù)端用哪把密鑰驗(yàn)簽?zāi)欠?wù)端自然就需要找到這把密鑰。很多實(shí)現(xiàn)是拿kid拼一個路徑從文件系統(tǒng)或配置中心讀取代碼大概長這樣String keyId jwtHeader.get(kid).toString(); String keyPath /etc/jwt_keys/ keyId .pem; byte[] keyBytes Files.readAllBytes(Paths.get(keyPath));這段代碼在安全視角下全是洞。kid是攻擊者可控的如果把kid設(shè)為../../../../etc/passwd服務(wù)端就會去讀系統(tǒng)文件然后拿著系統(tǒng)文件內(nèi)容去當(dāng)驗(yàn)簽密鑰。更常見的騷操作是設(shè)kid為/dev/null/dev/null的內(nèi)容是空字節(jié)如果你用的HMAC算法一個空密鑰就產(chǎn)生了攻擊者用空密鑰給token簽名服務(wù)端用空密鑰驗(yàn)簽一驗(yàn)一個準(zhǔn)。如果你在代碼評審里看到kid被拼進(jìn)路徑、SQL、或者任何命令里必須當(dāng)場打回。正確做法是kid只用來做索引查詢比如從數(shù)據(jù)庫里查出一個之前注冊好的密鑰記錄查詢時用參數(shù)綁定而不是字符串拼接。3.3 硬編碼密鑰與默認(rèn)密鑰nacos默認(rèn)密鑰繞過案例開頭提到的那個開源配置中心組件為什么會被默認(rèn)密鑰打穿我把過程簡化描述一下。該組件在早期版本里內(nèi)置了一個固定的簽名密鑰用于對其身份標(biāo)識字段做JWT簽名。組件文檔和源碼都公開密鑰等于公開給全世界。于是攻擊者只需要做兩步第一用已知的默認(rèn)密鑰自行構(gòu)造一個包含管理員身份信息的JWT第二把這個JWT放進(jìn)請求里發(fā)給管理端。組件驗(yàn)簽通過身份認(rèn)證被繞過。這個漏洞被收錄為CNVD-2023-17316之后官方給出的修復(fù)方案是升級版本改用用戶自定義的強(qiáng)密鑰并且提供密鑰配置入口。但從這個案例能學(xué)到的不只是升級到最新版這么簡單更重要的是自查習(xí)慣。我每次做項(xiàng)目安全評審都會先全局搜一下代碼里有沒有類似這樣的硬編碼密鑰private static final String JWT_SECRET nacos2023; private static final String JWT_SECRET secret; private static final String JWT_SECRET 123456;如果搜得到不管是測試代碼還是生產(chǎn)代碼都按漏洞處理。硬編碼密鑰的危害在于代碼會進(jìn)入Git倉庫、會同步到同事電腦、會被CI日志打印、會被外包看到泄露面完全不可控。正確做法是用環(huán)境變量或配置中心管理密鑰并且做到環(huán)境隔離測試環(huán)境一套、生產(chǎn)環(huán)境一套。另外密鑰輪換這件事很多人會忽略。密鑰不輪換時間越長泄露風(fēng)險越大。建議設(shè)計(jì)的時候就把kid用起來一個密鑰對應(yīng)一個kid輪換時新舊密鑰并行一段時間等舊token自然過期后再摘掉舊密鑰這樣能實(shí)現(xiàn)不踢用戶的無感知輪換。3.4 敏感信息泄露與重放攻擊JWT的Payload是明文這個特點(diǎn)放在安全機(jī)制完全指南里值得單獨(dú)劃重點(diǎn)。我見過一個真實(shí)項(xiàng)目登錄成功后把用戶的完整手機(jī)號、郵箱、還有內(nèi)部用戶ID全部塞進(jìn)payload理由是前端要用這些字段渲染頁面。結(jié)果前端頁面有XSS漏洞token被腳本偷走攻擊者解碼token直接拿到了用戶手機(jī)號這屬于可以寫進(jìn)事故報告的失誤。重放攻擊則是另一個維度的問題。假設(shè)token過期時間是兩個小時攻擊者在這兩個小時內(nèi)截獲了請求他不改token只是把原始請求原樣再發(fā)一遍。服務(wù)端怎么知道這是攻擊者發(fā)的答案是不知道。JWT無狀態(tài)服務(wù)端不做記錄就攔不住原樣重放。緩解手段包括縮短access token的過期時間、給token加jti并搭配短期緩存做使用記錄、關(guān)鍵操作轉(zhuǎn)賬、改密額外做一次性校驗(yàn)碼。別幻想一個JWT能解決所有鑒權(quán)問題有些場景你就是需要配合其他機(jī)制一起用。4. JWT安全落地的完整實(shí)現(xiàn)方案4.1 主流語言JWT庫選型與推薦配置不同語言的JWT庫質(zhì)量參差不齊我按自己實(shí)際用過的給你列一份。Java這邊我推薦io.jsonwebtoken:jjwt0.11.x以上API設(shè)計(jì)比較干凈算法白名單、過期校驗(yàn)都內(nèi)置Spring Security生態(tài)里也可以直接用spring-security-oauth2-jose里的NimbusJwtDecoder和框架整合度更高。Node.js首選jsonwebtoken用的人多、出問題搜得到Python推薦PyJWT輕量且支持算法白名單Go的話golang-jwt/jwt是社區(qū)維護(hù)最活躍的。選庫的時候最該看的三件事是否支持算法白名單、是否默認(rèn)校驗(yàn)過期時間、是否提供常量時間比較。我個人踩過一次坑某個庫版本較老解析token時需要手動調(diào)用setExpiration校驗(yàn)過期時間我漏了這一步結(jié)果過期token全部放行排查半天才定位到。參數(shù)配置上我給出自己的推薦值供參考配置項(xiàng)推薦值說明簽名算法RS256優(yōu)先或 HS256多服務(wù)間用RS256便于分發(fā)公鑰單體可用HS256但要保證密鑰強(qiáng)度AccessToken有效期15~30分鐘太短體驗(yàn)差太長泄露風(fēng)險大RefreshToken有效期7~30天配合續(xù)簽機(jī)制允許用戶長時間免登錄時鐘偏移容忍60秒防止多機(jī)時鐘不一致導(dǎo)致誤判過期密鑰長度HS256至少32字節(jié)RS256至少2048位密鑰太短就是給攻擊者送分必須校驗(yàn)字段exp、iss、aud三者全部校驗(yàn)才叫完整的驗(yàn)簽4.2 SPA項(xiàng)目中的驗(yàn)證碼與JWT登錄整合SPA項(xiàng)目里常見的登錄流程是賬號密碼加驗(yàn)證碼驗(yàn)證碼用JWT做登錄態(tài)管理。這里有一個很自然的整合方式我把完整流程拆給你看。第一步前端打開登錄頁向后端請求驗(yàn)證碼。后端生成圖片驗(yàn)證碼把正確答案存在Redis里key用captcha:{uuid}value就是驗(yàn)證碼答案同時設(shè)置5分鐘過期。注意這里必須用uuid關(guān)聯(lián)不能把驗(yàn)證碼塞進(jìn)JWT——驗(yàn)證碼是一次性的而JWT過期時間以分鐘甚至小時計(jì)兩者生命周期不匹配。第二步用戶輸入賬號、密碼、驗(yàn)證碼、uuid一起提交到登錄接口。后端先拿uuid去Redis取驗(yàn)證碼校驗(yàn)通過后刪除該key一次性使用然后再查賬號密碼。驗(yàn)證碼校驗(yàn)不通過的服務(wù)端會返回401并拒絕繼續(xù)處理這樣能避免對密碼字段做無意義的數(shù)據(jù)庫查詢。第三步賬號密碼正確后簽發(fā)兩個JWT。AccessToken有效期15分鐘RefreshToken有效期7天。Response返回這兩個token同時可以把用戶基本信息不要放手機(jī)號等敏感字段放AccessToken的payload里前端解碼后用于頁面渲染。第四步前端把AccessToken放在內(nèi)存或sessionStorage里放localStorage要謹(jǐn)慎XSS風(fēng)險更高每次請求用axios攔截器統(tǒng)一注入Authorization: Bearer頭。RefreshToken建議放HttpOnlyCookie里路徑限定在刷新接口。當(dāng)接口返回401時前端攔截器自動調(diào)用刷新接口換新AccessToken用戶無感知續(xù)期。這個方案的取舍點(diǎn)在于驗(yàn)證碼用Redis存儲服務(wù)端多了一次狀態(tài)依賴但驗(yàn)證碼本來就是一次性交互用Redis管理生命周期反而比塞進(jìn)JWT更合理。JWT負(fù)責(zé)的是登錄后的長效身份各管一攤職責(zé)清晰。4.3 Token續(xù)簽雙Token刷新機(jī)制完整實(shí)現(xiàn)JWT續(xù)簽這件事我見過太多人直接改exp重新簽一個甚至有人把AccessToken有效期設(shè)成30天來逃避續(xù)簽。這兩種做法都是拿安全換省事。標(biāo)準(zhǔn)的續(xù)簽方案是雙Token機(jī)制。AccessToken有效期短比如15分鐘用戶每次請求都帶上它服務(wù)端只驗(yàn)簽和查過期不做任何持久化狀態(tài)。RefreshToken有效期長比如7天專門用來換AccessToken。用戶AccessToken過期后前端拿RefreshToken去調(diào)刷新接口服務(wù)端驗(yàn)RefreshToken的簽名和有效期通過后簽發(fā)一個新的AccessToken。不需要用戶重新輸密碼體驗(yàn)上就是無感續(xù)期。RefreshToken要處理好三個細(xì)節(jié)。第一是保存方式RefreshToken不能扔給前端localStorage隨便存建議放HttpOnly Cookie限制SameSiteLax并設(shè)置Path/refresh只讓刷新接口的請求帶上它。第二是輪換每次使用RefreshToken刷新成功后服務(wù)端必須簽發(fā)一個新的RefreshToken同時讓舊的失效。這樣如果RefreshToken被偷攻擊者用一次、服務(wù)端輪換一次、用戶下一次刷新時發(fā)現(xiàn)舊RefreshToken失效就能感知到有人冒用從而實(shí)現(xiàn)失竊檢測。第三是吊銷RefreshToken在Redis里存一份key是它的jtivalue是用戶ID用戶主動退出時刪掉這個keyRefreshToken立即失效。刷新接口要防一個經(jīng)典漏洞重放刷新請求。攻擊者只要拿到一個RefreshToken在它過期之前能反復(fù)刷新?lián)Q新token相當(dāng)于永久登錄。配合RefreshToken輪換和短期使用記錄Redis存最近使用過的jti基本可以把重放窗口縮到很小。4.4 Spring Security JWT整合要點(diǎn)Java后端這些年最常用的組合就是Spring Security加JWT但很多人是一邊抄配置一邊踩坑。我直接給你梳理一條核心鏈路。Spring Security的過濾鏈?zhǔn)秦?zé)任鏈模式JWT整合的思路是在UsernamePasswordAuthenticationFilter之前插入一個自定義過濾器職責(zé)是從請求頭解析token、驗(yàn)簽、構(gòu)造Authentication對象放進(jìn)SecurityContextHolder。關(guān)鍵代碼如下public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtTokenProvider tokenProvider; public JwtAuthenticationFilter(JwtTokenProvider tokenProvider) { this.tokenProvider tokenProvider; } Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token resolveToken(request); if (token ! null tokenProvider.validateToken(token)) { Authentication auth tokenProvider.getAuthentication(token); SecurityContextHolder.getContext().setAuthentication(auth); } chain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearer request.getHeader(Authorization); if (bearer ! null bearer.startsWith(Bearer )) { return bearer.substring(7); } return null; } }然后把這個過濾器注冊進(jìn)安全配置同時把Session策略設(shè)成無狀態(tài)Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(STATELESS) .and() .authorizeHttpRequests() .requestMatchers(/api/auth/login, /api/auth/refresh, /captcha).permitAll() .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }這里有幾個特別容易出問題的點(diǎn)。第一csrf().disable()是因?yàn)槲覀冇玫氖荁earer Token模式本身不受CSRF影響但如果你換成了Cookie存token這條必須重新評估否則等于自己拆了一面盾。第二addFilterBefore位置寫錯會導(dǎo)致過濾器不生效記住一定要放在UsernamePasswordAuthenticationFilter之前。第三Spring Security的異常處理要單獨(dú)定義AuthenticationEntryPoint否則token過期時返回的是默認(rèn)的403而不是約定的401前端攔截器就傻眼了。5. 常見問題排查與加固清單5.1 高頻報錯速查表JWT在生產(chǎn)和測試中最常出現(xiàn)的報錯我整理成了一張表你Debug的時候可以直接對著看。報錯信息常見原因排查思路SignatureException密鑰不匹配或token被篡改確認(rèn)簽發(fā)和驗(yàn)簽密鑰是否一致檢查是否更換過密鑰ExpiredJwtExceptiontoken過期確認(rèn)系統(tǒng)時間和簽發(fā)時間是否一致檢查時鐘偏移設(shè)置MalformedJwtException格式錯誤檢查是否為三段式是否混入了換行符或多余空格UnsupportedJwtExceptionalg不匹配或token不完整檢查Header里的alg與服務(wù)端白名單是否一致IllegalArgumentException傳入空token確認(rèn)過濾器是否處理了缺失Authorization頭的場景解析出的payload亂碼Base64和Base64URL混用確認(rèn)解碼時用的是Base64URL刷新token一直失敗RefreshToken未輪換或已注銷檢查Redis里的狀態(tài)管理確認(rèn)輪換時新舊token是否沖突時鐘偏移這個坑我單獨(dú)強(qiáng)調(diào)一下。JWT里的exp和iat都是Unix時間戳單位是秒。但有些語言的標(biāo)準(zhǔn)時間戳接口返回的是毫秒比如Java的System.currentTimeMillis()和JavaScript的Date.now()寫校驗(yàn)邏輯前必須做一次除以1000的轉(zhuǎn)換。我曾經(jīng)在一次跨語言聯(lián)調(diào)中Java服務(wù)端簽發(fā)的token用JavaScript前端解析就是因?yàn)槊牒秃撩氲牟町悓?dǎo)致提前過期了排查了很久。5.2 你可能會忽略的細(xì)節(jié)除了報錯還有幾個細(xì)節(jié)如果你在集成階段不處理好線上會出各種玄學(xué)問題。第一個是網(wǎng)關(guān)與服務(wù)間的token透傳。微服務(wù)架構(gòu)里網(wǎng)關(guān)解完token后常常會把用戶信息放在Header轉(zhuǎn)發(fā)給下游服務(wù)比如X-User-Id。但如果網(wǎng)關(guān)不加白名單過濾外部請求偽造一個X-User-Id頭下游服務(wù)直接用就等于攻擊者自己填了個用戶ID。正確做法要么是下游繼續(xù)驗(yàn)簽原始token要么對內(nèi)部透傳Header做嚴(yán)格的來源控制。第二個是Authorization頭的大小寫和空格問題。標(biāo)準(zhǔn)格式是Authorization: Bearer token但有些客戶端會寫成bearer小寫或者在Bearer前多加一個空格。過濾器解析時最好用startsWith(Bearer )配合忽略大小寫去判斷或者干脆直接取空格后的最后一段別做嚴(yán)格的相等比較。第三個是密鑰強(qiáng)度和隨機(jī)性。很多人用UUID當(dāng)密鑰UUID本身是16進(jìn)制的字符集有限隨機(jī)性也沒有專門生成的密鑰強(qiáng)。建議用openssl rand -base64 48生成密鑰至少48字節(jié)然后放到配置中心管理。別自己拍腦袋編字符串人類編的密碼在暴力破解面前不值一提。5.3 安全加固檢查清單每次JWT模塊上線前我建議按這個清單自查一遍這也是我在項(xiàng)目里使用的檢查表簽名算法是否為白名單固定有沒有信任token里的alg字段密鑰是否通過環(huán)境變量/配置中心注入代碼和倉庫里有沒有硬編碼密鑰密鑰強(qiáng)度是否達(dá)標(biāo)HS256密鑰不低于32字節(jié)RefreshToken是否做了輪換和短期使用記錄是否校驗(yàn)了exp、iss、aud三個關(guān)鍵聲明payload里有沒有放身份證、手機(jī)號等敏感明文token存放位置是否避免lodged localStorage提醒自己如果確實(shí)用localStorage必須有緩解措施有沒有對關(guān)鍵操作額外增加一次性校驗(yàn)或二次驗(yàn)證過期token是否統(tǒng)一返回401并規(guī)范了異常響應(yīng)多服務(wù)場景下是否校驗(yàn)了token簽發(fā)者和受眾防止跨服務(wù)冒用這十條我至少幫同事復(fù)現(xiàn)過其中六條對應(yīng)的線上問題。每次多花十分鐘檢查省下來的都是凌晨的報警電話。最后再分享一個我自己養(yǎng)成的小習(xí)慣新項(xiàng)目里JWT模塊寫完我會順手用攻擊者視角構(gòu)造三組測試token一組algnone、一組改了kid為/dev/null、一組改簽名亂碼直接打到自己服務(wù)上。如果這三組里有任何一組通過了驗(yàn)簽這個服務(wù)絕不能上生產(chǎn)。這個自測動作成本極低但每次都能發(fā)現(xiàn)點(diǎn)意外之喜。你寫JWT相關(guān)的代碼時也不妨試試。