用JWT技術解決IM系統Socket長連線的身份認證痛點

Socket 加密解密 · 發表 2018-11-28 12:17:53

摘要：本文引用了封宇《JWT技術解決IM系統的認證痛點》一文的部分內容，即時通訊網重新整理、增補和修訂，感謝原作者的無私分享。 1、引言隨著瓜子二手車相關業務的發展，公司有多個業務線都接入了IM系統，IM系統中的Socket長連線的安全問題變得越來越重要。本次分享正是基於此次解決Socke...

本文引用了封宇《JWT技術解決IM系統的認證痛點》一文的部分內容，即時通訊網重新整理、增補和修訂，感謝原作者的無私分享。

1、引言

隨著瓜子二手車相關業務的發展，公司有多個業務線都接入了IM系統，IM系統中的Socket長連線的安全問題變得越來越重要。本次分享正是基於此次解決Socket長連線身份安全認證的實踐總結而來，方案可能並不完美，但願能起到拋磚引玉的作用，希望能給您的IM系統開發帶來啟發。

學習交流：

- 即時通訊/推送技術開發交流4群： ofollow,noindex">101279154 [推薦]

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM 》

（本文同步釋出於： http://www.52im.net/thread-2106-1-1.html ）

2、原作者

封宇： 瓜子二手車技術專家，中國計算機學會專業會員。主要負責瓜子即時訊息解決方案及相關係統研發工作。曾供職於58同城、華北計算技術研究所，參與到家訊息系統、58爬蟲系統以及多個國家級軍工科研專案的架構及研發工作。

封宇同時還分享了其它IM方面的技術實踐和總結，您可能也會感興趣：

《從零開始搭建瓜子二手車IM系統(PPT) [附件下載] 》

《一套海量線上使用者的移動端IM架構設計實踐分享(含詳細圖文) 》

《一個低成本確保IM訊息時序的方法探討》

《移動端IM中大規模群訊息的推送如何保證效率、實時性？》

3、系列文章

本文是IM通訊安全知識系列文章中的第7篇，總目錄如下：

《即時通訊安全篇（一）：正確地理解和使用 Android端加密演算法》

《即時通訊安全篇（二）：探討組合加密演算法在IM中的應用》

《即時通訊安全篇（三）：常用加解密演算法與通訊安全講解》

《即時通訊安全篇（四）：例項分析Android中金鑰硬編碼的風險》

《即時通訊安全篇（五）：對稱加密技術在Android上的應用實踐》

《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》

《即時通訊安全篇（七）：用JWT技術解決IM系統Socket長連線的身份認證痛點》（本文）

4、我們面臨的技術痛點

針對我們IM系統中的Socket長連線的身份認證安全問題，瓜子有統一登入認證系統SSO（即單點登陸系統，原理詳見《 IM開發基礎知識補課(一)：正確理解前置 HTTP SSO單點登陸介面的原理》）。

我們的IM長連線通道也利用這個系統做安全認證，結構如下圖：

如上圖所示，整個認證步驟如下：

1）使用者登入App，App從業務後臺拿到單點登陸系統SSO頒發的token；

2）當App需要使用IM功能時，將token傳給IM客服端SDK；

3）客服端SDK跟IM Server建立長連線的時候用token進行認證；

4）IM Server請求SSO單點登陸系統，確認token合法性。

* 補充：如您對SSO單點登陸系統的瞭解知之甚少，請務必先閱讀《 IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登陸介面的原理》。

咋一看，這個過程沒有什麼問題，但是IM（尤其是移動端IM）業務的特殊性，這個流程結構並不好。

為什麼說上面的流程結構對於移動端的IM來說並不好呢？原因如下：

1）網路不穩定： 手機（移動端）的網路很不穩定，進出地鐵可能斷網，挪動位置也可能換基站；

2）長連線頻繁建立和釋放： 正因為1）中的原因，在一個聊天會話過程中，會經常重新建立長連線，從而導致上圖裡的第3步會被頻繁執行，進而第4步也會頻繁執行；

3）系統壓力會增大： 鑑於2）中的表現，將大大增加了SSO單點登陸系統的壓力（因為IM例項需要頻繁的呼叫SSO系統，從而完全客戶端長連線的身份合法性檢查）；

4）使用者體驗也不好： 長連線建立過程中，因SSO單點登陸系統並不屬於IM服務端例項範圍之內，IM服務端例項與SSO系統的通訊等，帶來的額外通訊鏈路延遲對於使用者的體驗也是一種傷害（而且SSO系統也可能短暫開小差）。

如果不通過上圖中的第4步就能完成IM長連線的身份合法性驗證，那這個痛點會得到極大緩解。於是，我們便想到了JWT技術。

* 題外話：如果您對移動端弱網路的物理特性還不瞭解，那麼下面的文章有助於您建立起這方面的認知：

《現代移動端網路短連線的優化手段總結：請求速度、弱網適應、安全保障》

《移動端IM開發者必讀(一)：通俗易懂，理解行動網路的“弱”和“慢” 》

《移動端IM開發者必讀(二)：史上最全移動弱網路優化方法總結》

5、完全搞懂什麼是JWT技術

5.1 基礎知識

JSON Web Token（簡稱JWT），是一個開放安全的行業標準（詳見 RFC7519 ），可以用於多個系統之間傳遞安全可靠的資訊（也包括本文中將要用到的傳遞身份認證資訊的場景）。

一個完整的JWT的token字串是什麼樣子的結構？

▲ JWT說到底也是一個token字串，它由三部分組成：頭部、載荷與簽名

正如上圖中所示，一個JWT的token字串組成如下：

1）紅色的為Header：指定token型別與簽名型別；

2）紫色的為載荷（playload）：儲存使用者id等關鍵資訊；

3）藍色的為簽名：保證整個資訊的完整性、可靠性（這個簽名字串，相當於是一段被加密了的密文文字，安全性就是由它來決定的）。

5.2解密JWT的頭部（Header）

JWT的頭部用於描述關於該JWT的最基本的資訊，例如其型別以及簽名所用的演算法等。

這可以被表示成一個JSON物件：

{
"typ": "JWT",
"alg": "HS256"
}

▲ 在這個頭資訊裡，標明瞭這是一個JWT字串，並且所用的簽名演算法是HS256演算法

對它進行Base64編碼，之後的字串就成了JWT的Header（頭部），也就是你在5.1節中看到的紅色部分：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

（你可以自已試著進行Base64的加密和解決，比如用這個線上工具： http://tool.oschina.net/encrypt?type=3 ）

5.3 解密JWT的載荷(playload)

在載荷（playload）中可以定義以下屬性：

1）iss: 該JWT的簽發者；

2）sub: 該JWT所面向的使用者；

3）aud: 接收該JWT的一方；

4）exp(expires): 什麼時候過期，這裡是一個Unix時間戳；

5）iat(issued at): 在什麼時候簽發的。

上面的資訊也可以用一個JSON物件來描述，將上面的JSON物件進行base64編碼，可以得到下面的字串。

這個字串我們將它稱作JWT的Payload（載荷），以下字串樣例就是你在5.1節中看到的紫色部分：

eyJpc3MiOiIyOWZmMDE5OGJlOGM0YzNlYTZlZTA4YjE1MGRhNTU0NC1XRUIiLCJleHAiOjE1MjI0OTE5MTV9

（你可以自已試著進行Base64的加密和解決，比如用這個線上工具： http://tool.oschina.net/encrypt?type=3 ）

5.4 解決JWT的簽名（Signature）

JWT的簽名部分，在官方文件中是如下描述的：

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

上述偽碼的意義，即如下操作:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIyOWZmMDE5OGJlOGM0YzNlYTZlZTA4YjE1MGRhNTU0NC1XRUIiLCJleHAiOjE1MjI0OTE5MTV9

▲ 將上面的兩個base64編碼後的字串都用句號‘ . ’連線在一起（頭部在前），就形成了如下字串

最後，我們將上面拼接完的字串用HS256演算法進行加密。在加密的時候，我們還需要提供一個金鑰（secret）。

那麼，按照 RFC7519 上描述的方法，就可以得到我們加密後的內容：

P-k-vIzxElzyzFbzR4tUxAAET8xT9EP49b7hpcPazd0

▲ 這個就是我們需要的JWT的簽名部分了

5.5 簽名的目的

生成JWT的token字串的最後一步簽名過程，實際上是對頭部以及載荷內容進行加密。

一般而言： 加密演算法對於不同的輸入產生的輸出總是不一樣的。所以，如果有人對頭部以及載荷的內容解碼之後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道伺服器加密的時候用的金鑰的話，得出來的簽名也一定會是不一樣的。

換句話說： 你的JWT字串的安全強度，基本上就是由這個簽名部分來決定的。

使用時： 伺服器端在接受到JWT的token字串後，會首先用開發者指明的secret（可以理解為密碼）對頭部和載荷的內容用同一演算法再次簽名。那麼伺服器應用是怎麼知道我們用的是哪一種演算法呢？別忘了，我們在JWT的頭部中已經用alg欄位指明瞭我們的加密演算法了。

如果伺服器端對頭部和載荷再次以同樣方法簽名之後發現，自己計算出來的簽名和接受到的簽名不一樣，那麼就說明這個Token的內容被別人動過的，我們應該拒絕這個JWT Token，返回一個HTTP 401 Unauthorized響應。

5.6 一個典型的JWT應用流程

JWT是一個怎樣的流程? 先上個官方文件的圖：

如上圖所示，整個應用流程描述如下：

1）客戶端使用賬戶密碼請求登入介面；

2）登入成功後伺服器使用簽名金鑰生成JWT ,然後返回JWT給客戶端；

3）客戶端再次向服務端請求其他介面時帶上JWT；

4）服務端接收到JWT後驗證簽名的有效性.對客戶端做出相應的響應。

5.7 總而言之

JWT的整個技術原理，就是一個很典型的對稱加密應用過程，通俗的說也就是用開發者在服務端儲存的密碼，對使用者的id等資訊進行加密並按照JWT的規則（見5.1節）組成字串返回給使用者。使用者在使用時將這個字串提交給對應的服務端，服務端取出JWT字串的頭資訊、載荷，用開發者指明的密碼試著進行加密並得到一個字串（即合法的JWT token），兩相比較，相同則認為使用者提交上來的JWT合法，否則不合法。這就是JWT的全部原理，相當簡單易懂。

JWT技術的價值不在於具體的技術實現，而在於它的思想本身，尤其在異構系統、分散式系統方面，可以極大的簡化安全認證的成本，包括簡化架構複雜性、降低使用門檻等，因為JWT的技術原理決定了認證的過程不需要其它系統的參與，由當前例項自已就可以完成，而成認證程式碼極小（就是一個加密字串的比較而已）。

它的技術思路在當前的各種開發系統中應用廣泛，比如下圖中微信公眾號的服務介面配置裡，也用到了類似的思想：

另外，蘋果著名的APNs推送服務，也支援JWT技術，詳見《基於APNs最新HTTP/2介面實現 iOS的高效能訊息推送(服務端篇) 》第6.2節：

▲ 上述截圖內容摘錄自 NotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1" target="_blank" rel="nofollow,noindex">蘋果官方開發者文件

6、我們是怎樣使用JWT技術的？

上一章節，我們詳細理解了JWT技術的原理，那麼回到本文的初衷：我們該如何使用JWT技術來解決上面所提到的通點呢？

我們採用JWT驗證IM的Socket長連線流程如下：

如上圖所示，整個驗證過程描述如下：

1）使用者登入App（使用IM客服端SDK），App從業務後臺拿到SSO單點登陸系統頒發的token（注意：此token還不是JWT的token，它將在第3）步中被使用並生成真正的JWT token）；

2）當App需要使用IM功能時，將token傳給IM客服端SDK（這是在客戶端完成的，即當App的功能呼叫IM客服端SDK時傳入）；

3） IM客服端SDK將使用者名稱及第2步中得到的token發給後臺的JWT Server（簽發JWT token的模組），請求JWT token；

4）收到第3）步中提交過來的token後，JWT Server會通過RPC等技術向SSO系統提交驗證此token的合法性，如果合法，將用跟IM Server約定的Secret（你可以理解為這就是一個固定的密碼而已），根據業務需要簽發JWT token，並最終返回給IM客服端SDK（即完成第3步中的請求）。

5）後緒，IM客服端SDK將使用得到的JWT token請求IM Server驗證長連線，IM Server根據約定的演算法（不依賴其他系統直接用JWT的規則，加上第4）步中與JWT Server 約定的Secret）即可完成jwttoken合法性驗證。

通過上述努力，移動端在弱網情況下的頻繁建立長連線的身份驗證痛點得到了解決。