經(jīng)過(guò)前面兩篇文章《JSON Web Token - 在Web應(yīng)用間安全地傳遞信息》《八幅漫畫(huà)理解使用JSON Web Token設(shè)計(jì)單點(diǎn)登錄系統(tǒng)》的科普，相信大家應(yīng)該已經(jīng)知道了 JWT 協(xié)議是什么了。至少看到

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxaWFubWlJZCI6InFtMTAzNTNzaEQiLCJpc3MiOiJhcHBfcW0xMDM1M3NoRCIsInBsYXRmb3JtIjoiYXBwIn0.cMNwyDTFVYMLL4e7ts50GFHTvlSJLDpePtHXzu7z9j4 

這樣形如 A.B.C 的字符串時(shí)能敏感地認(rèn)出這是使用了 jwt。發(fā)了這兩篇文章后，有不少讀者在文末留言，表達(dá)了對(duì) jwt 使用方式的一些疑惑，以及到底哪些場(chǎng)景適合使用 jwt。我并不是 jwt 方面的專(zhuān)家，和不少讀者一樣，起初研究時(shí)我也存在相同疑惑，甚至在逐漸接觸后產(chǎn)生了更大的疑惑，經(jīng)過(guò)這段時(shí)間項(xiàng)目中的使用和一些自己思考，把個(gè)人的總結(jié)整理成此文。

編碼，簽名，加密

這些基礎(chǔ)知識(shí)簡(jiǎn)單地介紹下，千萬(wàn)別搞混了三個(gè)概念。在 jwt 中恰好同時(shí)涉及了這三個(gè)概念，筆者用大白話(huà)來(lái)做下通俗的講解（非嚴(yán)謹(jǐn)定義，供個(gè)人理解）

編碼(encode)和解碼(decode)

一般是編碼解碼是為了方便以字節(jié)的方式表示數(shù)據(jù)，便于存儲(chǔ)和網(wǎng)絡(luò)傳輸。整個(gè) jwt 串會(huì)被置于 http 的 Header 或者 url 中，為了不出現(xiàn)亂碼解析錯(cuò)誤等意外，編碼是有必要的。在 jwt 中以.分割的三個(gè)部分都經(jīng)過(guò) base64 編碼(secret 部分是否進(jìn)行 base64 編碼是可選的，header 和 payload 則是必須進(jìn)行 base64 編碼)。注意，編碼的一個(gè)特點(diǎn)：編碼和解碼的整個(gè)過(guò)程是可逆的。得知編碼方式后，整個(gè) jwt 串便是明文了，隨意找個(gè)網(wǎng)站驗(yàn)證下解碼后的內(nèi)容：

所以注意一點(diǎn)，payload 是一定不能夠攜帶敏感數(shù)據(jù)如密碼等信息的。

簽名(signature)

簽名的目的主要是為了驗(yàn)證我是“我”。jwt 中常用的簽名算法是 HS256，可能大多數(shù)人對(duì)這個(gè)簽名算法不熟悉，但 md5,sha 這樣的簽名算法肯定是為人熟知的，簽名算法共同的特點(diǎn)是整個(gè)過(guò)程是不可逆的。由于簽名之前的主體內(nèi)容(header,payload)會(huì)攜帶在 jwt 字符串中，所以需要使用帶有密鑰(yuè)的簽名算法，密鑰是服務(wù)器和簽發(fā)者共享的。header 部分和 payload 部分如果被篡改，由于篡改者不知道密鑰是什么，也無(wú)法生成新的 signature 部分，服務(wù)端也就無(wú)法通過(guò)，在 jwt 中，消息體是透明的，使用簽名可以保證消息不被篡改。

前面轉(zhuǎn)載的文章中，原作者將 HS256 稱(chēng)之為加密算法，不太嚴(yán)謹(jǐn)。

加密(encryption)

加密是將明文信息改變?yōu)殡y以讀取的密文內(nèi)容，使之不可讀。只有擁有解密方法的對(duì)象，經(jīng)由解密過(guò)程，才能將密文還原為正?？勺x的內(nèi)容。加密算法通常按照加密方式的不同分為對(duì)稱(chēng)加密(如 AES)和非對(duì)稱(chēng)加密(如 RSA)。你可能會(huì)疑惑：“jwt 中哪兒涉及加密算法了？”，其實(shí) jwt 的 第一部分(header) 中的 alg 參數(shù)便可以指定不同的算法來(lái)生成第三部分(signature)，大部分支持 jwt 的框架至少都內(nèi)置 rsa 這種非對(duì)稱(chēng)加密方式。這里誕生了第一個(gè)疑問(wèn)

疑問(wèn)：一提到 rsa，大多數(shù)人第一想到的是非對(duì)稱(chēng)加密算法，而 jwt 的第三部分明確的英文定義是 signature，這不是矛盾嗎？

劃重點(diǎn)！

rsa 加密和 rsa 簽名 是兩個(gè)概念！(嚇得我都換行了)

這兩個(gè)用法很好理解：

• 既然是加密，自然是不希望別人知道我的消息，只有我自己才能解密，所以公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密。這是大多數(shù)的使用場(chǎng)景，使用 rsa 來(lái)加密。

• 既然是簽名，自然是希望別人不能冒充我發(fā)消息，只有我才能發(fā)布簽名，所以私鑰負(fù)責(zé)簽名，公鑰負(fù)責(zé)驗(yàn)證。

所以，在客戶(hù)端使用 rsa 算法生成 jwt 串時(shí)，是使用私鑰來(lái)“加密”的，而公鑰是公開(kāi)的，誰(shuí)都可以解密，內(nèi)容也無(wú)法變更（篡改者無(wú)法得知私鑰）。

所以，在 jwt 中并沒(méi)有純粹的加密過(guò)程，而是使加密之虛，行簽名之實(shí)。

什么場(chǎng)景該適合使用jwt？

來(lái)聊聊幾個(gè)場(chǎng)景，注意，以下的幾個(gè)場(chǎng)景不是都和jwt貼合。

1. 一次性驗(yàn)證

比如用戶(hù)注冊(cè)后需要發(fā)一封郵件讓其激活賬戶(hù)，通常郵件中需要有一個(gè)鏈接，這個(gè)鏈接需要具備以下的特性：能夠標(biāo)識(shí)用戶(hù)，該鏈接具有時(shí)效性（通常只允許幾小時(shí)之內(nèi)激活），不能被篡改以激活其他可能的賬戶(hù)…這種場(chǎng)景就和 jwt 的特性非常貼近，jwt 的 payload 中固定的參數(shù)：iss 簽發(fā)者和 exp 過(guò)期時(shí)間正是為其做準(zhǔn)備的。

1. restful api 的無(wú)狀態(tài)認(rèn)證

使用 jwt 來(lái)做 restful api 的身份認(rèn)證也是值得推崇的一種使用方案?？蛻?hù)端和服務(wù)端共享 secret；過(guò)期時(shí)間由服務(wù)端校驗(yàn)，客戶(hù)端定時(shí)刷新；簽名信息不可被修改…spring security oauth jwt 提供了一套完整的 jwt 認(rèn)證體系，以筆者的經(jīng)驗(yàn)來(lái)看：使用 oauth2 或 jwt 來(lái)做 restful api 的認(rèn)證都沒(méi)有大問(wèn)題，oauth2 功能更多，支持的場(chǎng)景更豐富，后者實(shí)現(xiàn)簡(jiǎn)單。

1. 使用 jwt 做單點(diǎn)登錄+會(huì)話(huà)管理(不推薦)

在《八幅漫畫(huà)理解使用JSON Web Token設(shè)計(jì)單點(diǎn)登錄系統(tǒng)》一文中提及了使用 jwt 來(lái)完成單點(diǎn)登錄，本文接下來(lái)的內(nèi)容主要就是圍繞這一點(diǎn)來(lái)進(jìn)行討論。如果你正在考慮使用 jwt+cookie 代替 session+cookie ，我強(qiáng)力不推薦你這么做。

首先明確一點(diǎn)：使用 jwt 來(lái)設(shè)計(jì)單點(diǎn)登錄系統(tǒng)是一個(gè)不太嚴(yán)謹(jǐn)?shù)恼f(shuō)法。首先 cookie+jwt 的方案前提是非跨域的單點(diǎn)登錄(cookie 無(wú)法被自動(dòng)攜帶至其他域名)，其次單點(diǎn)登錄系統(tǒng)包含了很多技術(shù)細(xì)節(jié)，至少包含了身份認(rèn)證和會(huì)話(huà)管理，這還不涉及到權(quán)限管理。如果覺(jué)得比較抽象，不妨用傳統(tǒng)的 session+cookie 單點(diǎn)登錄方案來(lái)做類(lèi)比，通常我們可以選擇 spring security（身份認(rèn)證和權(quán)限管理的安全框架）和 spring session（session 共享）來(lái)構(gòu)建，而選擇用 jwt 設(shè)計(jì)單點(diǎn)登錄系統(tǒng)需要解決很多傳統(tǒng)方案中同樣存在和本不存在的問(wèn)題，以下一一詳細(xì)羅列。

jwt token泄露了怎么辦？

前面的文章下有不少人留言提到這個(gè)問(wèn)題，我則認(rèn)為這不是問(wèn)題。傳統(tǒng)的 session+cookie 方案，如果泄露了 sessionId，別人同樣可以盜用你的身份。揚(yáng)湯止沸不如釜底抽薪，不妨來(lái)追根溯源一下，什么場(chǎng)景會(huì)導(dǎo)致你的 jwt 泄露。

遵循如下的實(shí)踐可以盡可能保護(hù)你的 jwt 不被泄露：使用 https 加密你的應(yīng)用，返回 jwt 給客戶(hù)端時(shí)設(shè)置 httpOnly=true 并且使用 cookie 而不是 LocalStorage 存儲(chǔ) jwt，這樣可以防止 XSS 攻擊和 CSRF 攻擊（對(duì)這兩種攻擊感興趣的童鞋可以看下 spring security 中對(duì)他們的介紹CSRF,XSS）

你要是正在使用 jwt 訪(fǎng)問(wèn)一個(gè)接口，這個(gè)時(shí)候你的同事跑過(guò)來(lái)把你的 jwt 抄走了，這種泄露，恕在下無(wú)力

secret如何設(shè)計(jì)

jwt 唯一存儲(chǔ)在服務(wù)端的只有一個(gè) secret，個(gè)人認(rèn)為這個(gè) secret 應(yīng)該設(shè)計(jì)成和用戶(hù)相關(guān)的屬性，而不是一個(gè)所有用戶(hù)公用的統(tǒng)一值。這樣可以有效的避免一些注銷(xiāo)和修改密碼時(shí)遇到的窘境。

注銷(xiāo)和修改密碼

傳統(tǒng)的 session+cookie 方案用戶(hù)點(diǎn)擊注銷(xiāo)，服務(wù)端清空 session 即可，因?yàn)闋顟B(tài)保存在服務(wù)端。但 jwt 的方案就比較難辦了，因?yàn)?jwt 是無(wú)狀態(tài)的，服務(wù)端通過(guò)計(jì)算來(lái)校驗(yàn)有效性。沒(méi)有存儲(chǔ)起來(lái)，所以即使客戶(hù)端刪除了 jwt，但是該 jwt 還是在有效期內(nèi)，只不過(guò)處于一個(gè)游離狀態(tài)。分析下痛點(diǎn)：注銷(xiāo)變得復(fù)雜的原因在于 jwt 的無(wú)狀態(tài)。我提供幾個(gè)方案，視具體的業(yè)務(wù)來(lái)決定能不能接受。

• 僅僅清空客戶(hù)端的 cookie，這樣用戶(hù)訪(fǎng)問(wèn)時(shí)就不會(huì)攜帶 jwt，服務(wù)端就認(rèn)為用戶(hù)需要重新登錄。這是一個(gè)典型的假注銷(xiāo)，對(duì)于用戶(hù)表現(xiàn)出退出的行為，實(shí)際上這個(gè)時(shí)候攜帶對(duì)應(yīng)的 jwt 依舊可以訪(fǎng)問(wèn)系統(tǒng)。

• 清空或修改服務(wù)端的用戶(hù)對(duì)應(yīng)的 secret，這樣在用戶(hù)注銷(xiāo)后，jwt 本身不變，但是由于 secret 不存在或改變，則無(wú)法完成校驗(yàn)。這也是為什么將 secret 設(shè)計(jì)成和用戶(hù)相關(guān)的原因。

• 借助第三方存儲(chǔ)自己管理 jwt 的狀態(tài)，可以以 jwt 為 key，實(shí)現(xiàn)去 redis 一類(lèi)的緩存中間件中去校驗(yàn)存在性。方案設(shè)計(jì)并不難，但是引入 redis 之后，就把無(wú)狀態(tài)的 jwt 硬生生變成了有狀態(tài)了，違背了 jwt 的初衷。實(shí)際上這個(gè)方案和 session 都差不多了。

修改密碼則略微有些不同，假設(shè)號(hào)被到了，修改密碼（是用戶(hù)密碼，不是 jwt 的 secret）之后，盜號(hào)者在原 jwt 有效期之內(nèi)依舊可以繼續(xù)訪(fǎng)問(wèn)系統(tǒng)，所以?xún)H僅清空 cookie 自然是不夠的，這時(shí)，需要強(qiáng)制性的修改 secret。在我的實(shí)踐中就是這樣做的。

續(xù)簽問(wèn)題

續(xù)簽問(wèn)題可以說(shuō)是我抵制使用 jwt 來(lái)代替?zhèn)鹘y(tǒng) session 的最大原因，因?yàn)?jwt 的設(shè)計(jì)中我就沒(méi)有發(fā)現(xiàn)它將續(xù)簽認(rèn)為是自身的一個(gè)特性。傳統(tǒng)的 cookie 續(xù)簽方案一般都是框架自帶的，session 有效期 30 分鐘，30 分鐘內(nèi)如果有訪(fǎng)問(wèn)，session 有效期被刷新至 30 分鐘。而 jwt 本身的 payload 之中也有一個(gè) exp 過(guò)期時(shí)間參數(shù)，來(lái)代表一個(gè) jwt 的時(shí)效性，而 jwt 想延期這個(gè) exp 就有點(diǎn)身不由己了，因?yàn)?payload 是參與簽名的，一旦過(guò)期時(shí)間被修改，整個(gè) jwt 串就變了，jwt 的特性天然不支持續(xù)簽！

如果你一定要使用 jwt 做會(huì)話(huà)管理（payload 中存儲(chǔ)會(huì)話(huà)信息），也不是沒(méi)有解決方案，但個(gè)人認(rèn)為都不是很令人滿(mǎn)意

1. 每次請(qǐng)求刷新 jwt

jwt 修改 payload 中的 exp 后整個(gè) jwt 串就會(huì)發(fā)生改變，那…就讓它變好了，每次請(qǐng)求都返回一個(gè)新的 jwt 給客戶(hù)端。太暴力了，不用我贅述這樣做是多么的不優(yōu)雅，以及帶來(lái)的性能問(wèn)題。

但，至少這是最簡(jiǎn)單的解決方案。

1. 只要快要過(guò)期的時(shí)候刷新 jwt

一個(gè)上述方案的改造點(diǎn)是，只在最后的幾分鐘返回給客戶(hù)端一個(gè)新的 jwt。這樣做，觸發(fā)刷新 jwt 基本就要看運(yùn)氣了，如果用戶(hù)恰巧在最后幾分鐘訪(fǎng)問(wèn)了服務(wù)器，觸發(fā)了刷新，萬(wàn)事大吉；如果用戶(hù)連續(xù)操作了 27 分鐘，只有最后的 3 分鐘沒(méi)有操作，導(dǎo)致未刷新 jwt，無(wú)疑會(huì)令用戶(hù)抓狂。

1. 完善 refreshToken

借鑒 oauth2 的設(shè)計(jì)，返回給客戶(hù)端一個(gè) refreshToken，允許客戶(hù)端主動(dòng)刷新 jwt。一般而言，jwt 的過(guò)期時(shí)間可以設(shè)置為數(shù)小時(shí)，而 refreshToken 的過(guò)期時(shí)間設(shè)置為數(shù)天。

我認(rèn)為該方案并可行性是存在的，但是為了解決 jwt 的續(xù)簽把整個(gè)流程改變了，為什么不考慮下 oauth2 的 password 模式和 client 模式呢？

1. 使用 redis 記錄獨(dú)立的過(guò)期時(shí)間

實(shí)際上我的項(xiàng)目中由于歷史遺留問(wèn)題，就是使用 jwt 來(lái)做登錄和會(huì)話(huà)管理的，為了解決續(xù)簽問(wèn)題，我們?cè)?redis 中單獨(dú)會(huì)每個(gè) jwt 設(shè)置了過(guò)期時(shí)間，每次訪(fǎng)問(wèn)時(shí)刷新 jwt 的過(guò)期時(shí)間，若 jwt 不存在與 redis 中則認(rèn)為過(guò)期。

tips:精確控制 redis 的過(guò)期時(shí)間不是件容易的事，可以參考我最近的一篇借助于 spring session 講解 redis 過(guò)期時(shí)間的排坑記錄。

同樣改變了 jwt 的流程，不過(guò)嘛，世間安得兩全法。我只能奉勸各位還未使用 jwt 做會(huì)話(huà)管理的朋友，盡量還是選用傳統(tǒng)的 session+cookie 方案，有很多成熟的分布式 session 框架和安全框架供你開(kāi)箱即用。

jwt,oauth2,session千絲萬(wàn)縷的聯(lián)系

具體的對(duì)比不在此文介紹，就一位讀者的留言回復(fù)下它的提問(wèn)

這么長(zhǎng)一個(gè)字符串，還不如我把數(shù)據(jù)存到數(shù)據(jù)庫(kù)，給一個(gè)長(zhǎng)的很難碰撞的key來(lái)映射，也就是專(zhuān)用token。

這位兄弟認(rèn)為 jwt 太長(zhǎng)了，是不是可以考慮使用和 oauth2 一樣的 uuid 來(lái)映射。這里面自然是有問(wèn)題的，jwt 不僅僅是作為身份的認(rèn)證（驗(yàn)證簽名是否正確，簽發(fā)者是否存在，有限期是否過(guò)期），還在其 payload 中存儲(chǔ)著會(huì)話(huà)信息，這是 jwt 和 session 的最大區(qū)別，一個(gè)在客戶(hù)端攜帶會(huì)話(huà)信息，一個(gè)在服務(wù)端存儲(chǔ)會(huì)話(huà)信息。如果真的是要將 jwt 的信息置于在共享存儲(chǔ)中，那再找不到任何使用 jwt 的意義了。

jwt 和 oauth2 都可以用于 restful 的認(rèn)證，就我個(gè)人的使用經(jīng)驗(yàn)來(lái)看，spring security oauth2 可以很好的使用多種認(rèn)證模式：client 模式，password 模式，implicit 模式（authorization code 模式不算單純的接口認(rèn)證模式），也可以很方便的實(shí)現(xiàn)權(quán)限控制，什么樣的 api 需要什么樣的權(quán)限，什么樣的資源需要什么樣的 scope…而 jwt 我只用它來(lái)實(shí)現(xiàn)過(guò)身份認(rèn)證，功能較為單一（可能是我沒(méi)發(fā)現(xiàn)更多用法）。

總結(jié)

在 web 應(yīng)用中，使用 jwt 代替 session 存在不小的風(fēng)險(xiǎn)，你至少得解決本文中提及的那些問(wèn)題，絕大多數(shù)情況下，傳統(tǒng)的 cookie-session 機(jī)制工作得更好。jwt 適合做簡(jiǎn)單的 restful api 認(rèn)證，頒發(fā)一個(gè)固定有效期的 jwt，降低 jwt 暴露的風(fēng)險(xiǎn)，不要對(duì) jwt 做服務(wù)端的狀態(tài)管理，這樣才能體現(xiàn)出 jwt 無(wú)狀態(tài)的優(yōu)勢(shì)。

可能對(duì) jwt 的使用場(chǎng)景還有一些地方未被我察覺(jué)，后續(xù)會(huì)研究下 spring security oauth jwt 的源碼，不知到時(shí)會(huì)不會(huì)有新發(fā)現(xiàn)。