引言
在上篇文章中，我們介紹了什么是JWT(JSON Web Token) 以及他的簡(jiǎn)單應(yīng)用，本文主要探究的是在IM系統(tǒng)中利用JWT解決Socket長(zhǎng)連接身份安全認(rèn)真的問(wèn)題，主要參考了《用JWT技術(shù)解決IM系統(tǒng)Socket長(zhǎng)連接的身份認(rèn)證痛點(diǎn)》。
要解決什么問(wèn)題
首先，整個(gè)通信過(guò)程如圖下所示：
系統(tǒng)通信過(guò)程
整個(gè)認(rèn)證過(guò)程步驟為：
- 用戶(hù)登陸App，App從服務(wù)端獲取到SSO（即單點(diǎn)登陸）系統(tǒng)生成的token；
- 當(dāng)App需要使用IM功能時(shí)， 將Token傳給IM服務(wù)端SDK；
- 客戶(hù)端和IM服務(wù)端進(jìn)行身份認(rèn)證；
- IM系統(tǒng)請(qǐng)求SSO確認(rèn)token的合法性，然后創(chuàng)建長(zhǎng)鏈接。
問(wèn)題在于， 當(dāng)網(wǎng)絡(luò)不穩(wěn)定的時(shí)候，移動(dòng)端應(yīng)用這一場(chǎng)景尤為明顯。長(zhǎng)連接會(huì)被頻繁的釋放和重連，這樣就造成了上圖的3 4兩步會(huì)被頻繁的執(zhí)行，從而導(dǎo)致SSO系統(tǒng)壓力加劇，況且還有額外的通信時(shí)間損耗，用戶(hù)體驗(yàn)也不盡人意。
怎樣應(yīng)用JWT
如何利用JWT解決上面的痛點(diǎn)呢？
升級(jí)后通信過(guò)程
如上圖所示，整個(gè)驗(yàn)證過(guò)程為：
- 用戶(hù)登陸App，app從業(yè)務(wù)服務(wù)端獲取SSO頒發(fā)的token（這里的token并不是JWT）
- 當(dāng)App需要使用IM時(shí)，將token傳給IM客戶(hù)端SDK
- IM客戶(hù)端SDK將token發(fā)送到后臺(tái)的JWT模塊，獲取JWT
- 收到3中提交過(guò)來(lái)的token后，會(huì)請(qǐng)求SSO驗(yàn)證token的合法性，如果合法，再用跟IM服務(wù)端約定好的密鑰來(lái)簽發(fā)真正的JWT，最終返回給客戶(hù)端SDK，完成第3步中的請(qǐng)求。
- 最終，IM客戶(hù)端SDK利用得到的JWT請(qǐng)求IM服務(wù)端建立長(zhǎng)連接，IM系統(tǒng)根據(jù)約定好的密鑰與算法，即可完成身份驗(yàn)證，建立鏈接。
這樣以來(lái)，連接斷開(kāi)時(shí)，僅僅需要重復(fù)步驟5就可以重新建立鏈接，problems solved!
JWT 的缺點(diǎn)
雖然JWT十分應(yīng)用，但也有不少缺點(diǎn)，選擇JWT時(shí)應(yīng)該權(quán)衡這些優(yōu)缺點(diǎn)
- JWT服務(wù)端不會(huì)保存會(huì)話(huà)狀態(tài)，所以不能主動(dòng)使其失效，一旦簽發(fā)，過(guò)期前將會(huì)一直有效。
- JWT中的header和payload都是可以反向解碼的，因此如果被盜取，其中的信息也就泄露了，所以不應(yīng)該將敏感信息寫(xiě)入JWT，并且要設(shè)置合理的過(guò)期時(shí)間。
因?yàn)橐陨显?，JWT一般基于HTTPS通信來(lái)保障其安全性，不建議使用明文傳輸?shù)腍TTP。
