JWT实现token-based会话管理
上文《3種web會話管理的方式》介紹了3種會話管理的方式，其中token-based的方式有必要從實現(xiàn)層面了解一下。本文主要介紹這方面的內(nèi)容。上文提到token-based的實現(xiàn)目前有一個開放的標(biāo)準(zhǔn)可用，這個標(biāo)準(zhǔn)就是JWT，從它的官網(wǎng)上也能看到，目前實現(xiàn)了JWT的技術(shù)非常多，基本上涵蓋了所有的語言平臺。本文選擇express和jsonwebtoken基于nodejs來實現(xiàn)token-based會話管理。
相關(guān)代碼：https://github.com/liuyunzhuge/blog/tree/master/node_jwt
demo的說明我會在本文第二部分介紹，下面先介紹一下JWT的相關(guān)知識。
認識JWT
JSON Web Token（JWT）是一個開放標(biāo)準(zhǔn)（RFC 7519），它定義了一種緊湊和自包含的方式，用于在各方之間作為JSON對象安全地傳輸信息。作為標(biāo)準(zhǔn)，它沒有提供技術(shù)實現(xiàn)，但是大部分的語言平臺都有按照它規(guī)定的內(nèi)容提供了自己的技術(shù)實現(xiàn)，所以實際在用的時候，只要根據(jù)自己當(dāng)前項目的技術(shù)平臺，到官網(wǎng)上選用合適的實現(xiàn)庫即可。
使用JWT來傳輸數(shù)據(jù)，實際上傳輸?shù)氖且粋€字符串，這個字符串就是所謂的json web token字符串。所以廣義上，JWT是一個標(biāo)準(zhǔn)的名稱；狹義上，JWT指的就是用來傳遞的那個token字符串。這個串有兩個特點：
1）緊湊：指的是這個串很小，能通過url 參數(shù)，http 請求提交的數(shù)據(jù)以及http header的方式來傳遞；
2）自包含：這個串可以包含很多信息，比如用戶的id、角色等，別人拿到這個串，就能拿到這些關(guān)鍵的業(yè)務(wù)信息，從而避免再通過數(shù)據(jù)庫查詢等方式才能得到它們。
通常一個JWT是長這個樣子的（這個串本來是不會換行的，為了讓這個串看起來的樣子跟后面要介紹的數(shù)據(jù)結(jié)構(gòu)對應(yīng)起來才手工加的換行）：
?
要知道一個JWT是怎么產(chǎn)生以及如何用于會話管理，只要弄清楚JWT的數(shù)據(jù)結(jié)構(gòu)以及它簽發(fā)和驗證的過程即可。
1）JWT的數(shù)據(jù)結(jié)構(gòu)以及簽發(fā)過程
一個JWT實際上是由三個部分組成：header（頭部）、payload（載荷）和signature（簽名）。這三個部分在JWT里面分別對應(yīng)英文句號分隔出來的三個串：
先來看header部分的結(jié)構(gòu)以及它的生成方法。header部分是由下面格式的json結(jié)構(gòu)生成出來：
這個json中的typ屬性，用來標(biāo)識整個token字符串是一個JWT字符串；它的alg屬性，用來說明這個JWT簽發(fā)的時候所使用的簽名和摘要算法，常用的值以及對應(yīng)的算法如下：
typ跟alg屬性的全稱其實是type跟algorithm，分別是類型跟算法的意思。之所以都用三個字母來表示，也是基于JWT最終字串大小的考慮，同時也是跟JWT這個名稱保持一致，這樣就都是三個字符了…typ跟alg是JWT中標(biāo)準(zhǔn)中規(guī)定的屬性名稱，雖然在簽發(fā)JWT的時候，也可以把這兩個名稱換掉，但是如果隨意更換了這個名稱，就有可能在JWT驗證的時候碰到問題，因為拿到JWT的人，默認會根據(jù)typ和alg去拿JWT中的header信息，當(dāng)你改了名稱之后，顯然別人是拿不到header信息的，他又不知道你把這兩個名字換成了什么。JWT作為標(biāo)準(zhǔn)的意義在于統(tǒng)一各方對同一個事情的處理方式，各個使用方都按它約定好的格式和方法來簽發(fā)和驗證token，這樣即使運行的平臺不一樣，也能夠保證token進行正確的傳遞。
一般簽發(fā)JWT的時候，header對應(yīng)的json結(jié)構(gòu)只需要typ和alg屬性就夠了。JWT的header部分是把前面的json結(jié)構(gòu)，經(jīng)過Base64Url編碼之后生成出來的：
（在線base64編碼：http://www1.tc711.com/tool/BASE64.htm）
再來看payload部分的結(jié)構(gòu)和生成過程。payload部分是由下面類似格式的json結(jié)構(gòu)生成出來：
payload的json結(jié)構(gòu)并不像header那么簡單，payload用來承載要傳遞的數(shù)據(jù)，它的json結(jié)構(gòu)實際上是對JWT要傳遞的數(shù)據(jù)的一組聲明，這些聲明被JWT標(biāo)準(zhǔn)稱為claims，它的一個“屬性值對”其實就是一個claim，每一個claim的都代表特定的含義和作用。比如上面結(jié)構(gòu)中的sub代表這個token的所有人，存儲的是所有人的ID；name表示這個所有人的名字；admin表示所有人是否管理員的角色。當(dāng)后面對JWT進行驗證的時候，這些claim都能發(fā)揮特定的作用。
根據(jù)JWT的標(biāo)準(zhǔn)，這些claims可以分為以下三種類型：
a. Reserved claims（保留），它的含義就像是編程語言的保留字一樣，屬于JWT標(biāo)準(zhǔn)里面規(guī)定的一些claim。JWT標(biāo)準(zhǔn)里面定好的claim有：
- iss(Issuser)：代表這個JWT的簽發(fā)主體；
- sub(Subject)：代表這個JWT的主體，即它的所有人；
- aud(Audience)：代表這個JWT的接收對象；
- exp(Expiration time)：是一個時間戳，代表這個JWT的過期時間；
- nbf(Not Before)：是一個時間戳，代表這個JWT生效的開始時間，意味著在這個時間之前驗證JWT是會失敗的；
- iat(Issued at)：是一個時間戳，代表這個JWT的簽發(fā)時間；
- jti(JWT ID)：是JWT的唯一標(biāo)識。
b. Public claims，略（不重要）
c. Private claims，這個指的就是自定義的claim。比如前面那個結(jié)構(gòu)舉例中的admin和name都屬于自定的claim。這些claim跟JWT標(biāo)準(zhǔn)規(guī)定的claim區(qū)別在于：JWT規(guī)定的claim，JWT的接收方在拿到JWT之后，都知道怎么對這些標(biāo)準(zhǔn)的claim進行驗證；而private claims不會驗證，除非明確告訴接收方要對這些claim進行驗證以及規(guī)則才行。
按照JWT標(biāo)準(zhǔn)的說明：保留的claims都是可選的，在生成payload不強制用上面的那些claim，你可以完全按照自己的想法來定義payload的結(jié)構(gòu)，不過這樣搞根本沒必要：第一是，如果把JWT用于認證， 那么JWT標(biāo)準(zhǔn)內(nèi)規(guī)定的幾個claim就足夠用了，甚至只需要其中一兩個就可以了，假如想往JWT里多存一些用戶業(yè)務(wù)信息，比如角色和用戶名等，這倒是用自定義的claim來添加；第二是，JWT標(biāo)準(zhǔn)里面針對它自己規(guī)定的claim都提供了有詳細的驗證規(guī)則描述，每個實現(xiàn)庫都會參照這個描述來提供JWT的驗證實現(xiàn)，所以如果是自定義的claim名稱，那么你用到的實現(xiàn)庫就不會主動去驗證這些claim。
最后也是把這個json結(jié)構(gòu)做base64url編碼之后，就能生成payload部分的串：
（在線base64編碼：http://www1.tc711.com/tool/BASE64.htm）
最后看signature部分的生成過程。簽名是把header和payload對應(yīng)的json結(jié)構(gòu)進行base64url編碼之后得到的兩個串用英文句點號拼接起來，然后根據(jù)header里面alg指定的簽名算法生成出來的。算法不同，簽名結(jié)果不同，但是不同的算法最終要解決的問題是一樣的。以alg: HS256為例來說明前面的簽名如何來得到。按照前面alg可用值的說明，HS256其實包含的是兩種算法：HMAC算法和SHA256算法，前者用于生成摘要，后者用于對摘要進行數(shù)字簽名。這兩個算法也可以用HMACSHA256來統(tǒng)稱。運用HMACSHA256實現(xiàn)signature的算法是：
正好找到一個在線工具能夠測試這個簽名算法的結(jié)果，比如我們拿前面的header和payload串來測試，并把“secret”這個字符串就當(dāng)成密鑰來測試：
（https://1024tools.com/hmac）
最后的結(jié)果B其實就是JWT需要的signature。不過對比我在介紹JWT的開始部分給出的JWT的舉例：
會發(fā)現(xiàn)通過在線工具生成的header與payload都與這個舉例中的對應(yīng)部分相同，但是通過在線工具生成的signature與上面圖中的signature有細微區(qū)別，在于最后是否有“=”字符。這個區(qū)別產(chǎn)生的原因在于上圖中的JWT是通過JWT的實現(xiàn)庫簽發(fā)的JWT，這些實現(xiàn)庫最后編碼的時候都用的是base64url編碼，而前面那些在線工具都是bas64編碼，這兩種編碼方式不完全相同，導(dǎo)致編碼結(jié)果有區(qū)別。
以上就是一個JWT包含的全部內(nèi)容以及它的簽發(fā)過程。接下來看看該如何去驗證一個JWT是否為一個有效的JWT。
2）JWT的驗證過程
這個部分介紹JWT的驗證規(guī)則，主要包括簽名驗證和payload里面各個標(biāo)準(zhǔn)claim的驗證邏輯介紹。只有驗證成功的JWT，才能當(dāng)做有效的憑證來使用。
先說簽名驗證。當(dāng)接收方接收到一個JWT的時候，首先要對這個JWT的完整性進行驗證，這個就是簽名認證。它驗證的方法其實很簡單，只要把header做base64url解碼，就能知道JWT用的什么算法做的簽名，然后用這個算法，再次用同樣的邏輯對header和payload做一次簽名，并比較這個簽名是否與JWT本身包含的第三個部分的串是否完全相同，只要不同，就可以認為這個JWT是一個被篡改過的串，自然就屬于驗證失敗了。接收方生成簽名的時候必須使用跟JWT發(fā)送方相同的密鑰，意味著要做好密鑰的安全傳遞或共享。
再來看payload的claim驗證，拿前面標(biāo)準(zhǔn)的claim來一一說明：
- iss(Issuser)：如果簽發(fā)的時候這個claim的值是“a.com”，驗證的時候如果這個claim的值不是“a.com”就屬于驗證失敗；
- sub(Subject)：如果簽發(fā)的時候這個claim的值是“l(fā)iuyunzhuge”，驗證的時候如果這個claim的值不是“l(fā)iuyunzhuge”就屬于驗證失敗；
- aud(Audience)：如果簽發(fā)的時候這個claim的值是“['b.com','c.com']”，驗證的時候這個claim的值至少要包含b.com，c.com的其中一個才能驗證通過；
- exp(Expiration time)：如果驗證的時候超過了這個claim指定的時間，就屬于驗證失敗；
- nbf(Not Before)：如果驗證的時候小于這個claim指定的時間，就屬于驗證失敗；
- iat(Issued at)：它可以用來做一些maxAge之類的驗證，假如驗證時間與這個claim指定的時間相差的時間大于通過maxAge指定的一個值，就屬于驗證失敗；
- jti(JWT ID)：如果簽發(fā)的時候這個claim的值是“1”，驗證的時候如果這個claim的值不是“1”就屬于驗證失敗
需要注意的是，在驗證一個JWT的時候，簽名認證是每個實現(xiàn)庫都會自動做的，但是payload的認證是由使用者來決定的。因為JWT里面可能不會包含任何一個標(biāo)準(zhǔn)的claim，所以它不會自動去驗證這些claim。
以登錄認證來說，在簽發(fā)JWT的時候，完全可以只用sub跟exp兩個claim，用sub存儲用戶的id，用exp存儲它本次登錄之后的過期時間，然后在驗證的時候僅驗證exp這個claim，以實現(xiàn)會話的有效期管理。
以上就是我覺得需要介紹的JWT的各方面的內(nèi)容，希望大家能看的明白。主要參考的資料有：
https://jwt.io/introduction/
http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
https://www.iana.org/assignments/jwt/jwt.xml#IESG
接下來看看本文相關(guān)demo的內(nèi)容。
demo要點說明
這個demo分為兩個文件夾，一個api，一個client，分別模擬一個需要登錄認證的服務(wù)，以及一個發(fā)起登錄認證請求的客戶端：
這兩個文件下的內(nèi)容都是用express框架簡單搭建的，不了解express的話，可以去它官網(wǎng)上看看相關(guān)文檔，這兩個文件夾并沒有用太多express的東西，主要滿足demo的需要。
在這兩個文件夾下分別運行node app命令，就能啟動兩個服務(wù)：
然后打開瀏覽輸入http://localhost:2000，就能看到客戶端的服務(wù)了：
客戶端的頁面提供了三個接口調(diào)用的按鈕，作用分別是發(fā)起登錄驗證（獲取token），以及登錄驗證后獲取用戶信息（獲取用戶信息），模擬退出（銷毀token）。只有登錄驗證之后，獲取用戶信息的接口才能拿到數(shù)據(jù)。
客戶端在token-based的認證里面，主要是完成token的保存和發(fā)送工作。當(dāng)token從服務(wù)器返回后，我把它直接存放到了localStorage里面：
然后當(dāng)發(fā)送請求的時候，我會從localStorage里面拿出來，然后把token以Bearer token的形式加到http Authorization這個header里面：
當(dāng)ajax請求發(fā)送的時候，這個token就會跟著request header一起發(fā)送到服務(wù)端：
服務(wù)端在token-based認證里面主要的事情有：用戶的驗證、token的簽發(fā)、從http中解析出token串、token的驗證、token的刷新等。
由于這是個簡單的demo，所以用戶的驗證，也沒有用數(shù)據(jù)庫查詢這種級別的方式，直接用用戶名密碼寫死的方式來處理，代碼都在user.js這個模塊里面。
token的簽發(fā)和認證，我用的是node-jsonwebtoken這個JWT的實現(xiàn)，它基于nodejs，用起來相對比較簡單，它的github主頁都有詳細的使用說明。
在前面介紹token的簽發(fā)和簽名認證的時候，我用的都是HS256的算法，這是考慮這個算法網(wǎng)上有在線工具可用。在demo里面，我用的是RS256的算法，這個算法由于用到RSA算法來加密解密，它是一個非對稱加密的算法。需要一對密鑰才能完成加密和解密。所以我用windows的openssl工具來生成rsa所需要的密鑰對，也就是這兩個文件：
這個工具可以從這個地址下載：https://indy.fulgan.com/SSL/
生成的方法可以參考：http://blog.csdn.net/yhl_jxy/article/details/51538332
在簽發(fā)token的時候，我會讀取這兩個文件用于JWT的簽發(fā)和驗證：
整個token的管理我都封裝在authentication.js這個模塊里面。它的邏輯并不復(fù)雜，關(guān)鍵在于理解node-jsonwebtoken的用法，所以需要花點時間去它主頁上看它使用說明才行。唯一需要補充一點的就是這個模塊內(nèi)如何從http里面解析出token串：
其實也就是拿authorization這個header，然后按照Bearer token的格式進行解析就行了?？紤]到token可能通過url傳遞，所以這里面也多加了一個直接從url解析token的處理。
客戶端的主模塊文件app.js沒有要介紹的，服務(wù)端的主模塊app.js內(nèi)容較多，可以把一些要點再說明一下。首先因為token的管理都統(tǒng)一封裝起來了，所以我在服務(wù)啟動的時候就初始化了一個Authentication的實例：
它提供兩個回調(diào)，分別用來從請求中獲取用戶密碼，以及根據(jù)用戶密碼完成用戶信息的驗證。
然后我通過CORS（跨域資源共享）的設(shè)置來使得客戶端的ajax請求能夠順利地從服務(wù)端拿到數(shù)據(jù)，而不會引發(fā)跨域的攔截：
細心的話，在客戶端里面，發(fā)起獲取用戶信息的請求時，會從network里面看到兩個http請求，其中第一個請求是OPTIONS請求，這個是CORS導(dǎo)致的，如果想了解這個請求產(chǎn)生的具體原因，可以從以下兩篇文章詳細了解CORS的相關(guān)介紹：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Server-Side_Access_Control
http://www.ruanyifeng.com/blog/2016/04/cors.html
最后在客戶端對應(yīng)的請求路由里面，我會繼續(xù)用到authorization的實例來完成一些token相關(guān)的工作。比如這個登錄的路由：
最終通過authorization實例的generateToken方法來完成用戶的登錄信息驗證和token的簽發(fā)工作。
這個demo的代碼其實很好理解，我也是從中抽取一些我認為比較關(guān)鍵的點拿到博客里來單獨介紹，實際上你要是沒看明白上面的某些內(nèi)容，完全可以自己把demo弄到本地進行研究，相信那樣會有更好的效果。如果遇到問題或者發(fā)現(xiàn)錯誤，歡迎隨時跟我反饋交流。
小結(jié)
以上就是整個使用JWT來完成token-based會話管理的方案介紹。它跟我在上文介紹的內(nèi)容其實有一個差別，就是JWT在傳遞的過程中其實僅僅只做了base64url編碼，而不是加密處理，所以當(dāng)別人攔截到正常用戶的JWT的時候是很容易解碼看到其中的信息的，尤其是一些重要的業(yè)務(wù)信息。所以在真正使用的時候，是值得對JWT做一次整體的加密和解密處理的。
與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖總結(jié)
以上是生活随笔為你收集整理的JWT实现token-based会话管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用graphite和grafana进行
- 下一篇： 【OC】【一秒就会】【collectio