即时通讯IM安防性能（七）：JWT技术分析IM即时通讯系统Socket长连接认证

1，简介

随着瓜子二手车相关业务的发展，该公司拥有多条业务线，所有业务线都连接到IM系统，  IM系统长连接的安全性问题变得越来越重要。 此共享基于解决Socket长连接身份安全认证的实践的总结。 解决方案可能不是完美的。 我希望它可以在启发他人方面发挥作用。 我希望它将为您的IM系统开发带来启发。  

 2。 原作者

即时消息安全性（7）：使用JWT技术解决IM系统的身份认证问题Socket长连接_a.jpg 

冯宇：瓜子二手车技术专家，中文专业会员 计算机学会。 主要负责瓜子即时通讯解决方案及相关系统的研发。 他曾在58同城和华北计算技术学院工作，曾参与过大甲新闻系统，58爬行动物系统的体系结构和研发以及多项国家军事研究项目。  

 Feng Yu还分享了其他IM技术实践和摘要，您可能也感兴趣：

《从头开始构建瓜子种子汽车IM系统（PPT）[附件下载]] [H  ]“一组大量的在线用户的移动终端IM体系结构设计实践共享（包括详细的图形）” 

“一种确保IM消息定时的低成本方法” 

《移动终端IM CUHK  ” [H]《瓜子IM智能客服系统数据结构设计[下载附件]》 

《瓜子IM智能客服数据结构设计》 系统（从现场演讲中收集，并带有PPT支持）》 

》即时消息传递安全性（7）：使用JWT技术解决IM系统长套接字连接的身份验证难题[

 [h  ] 3，系列文章

本文是有关IM通信安全知识的系列文章中的第七篇 ent如下：

“即时消息传递安全性（1）：在Android端正确理解并使用加密算法” 

“即时消息传递安全性（2）：探索IM中的组合加密算法” 应用程序” 

“即时消息传递安全性（3）：常见的加密和解密算法和通信安全性说明” 

“即时消息传递安全性（4）：Android中密钥硬编码风险的示例分析” [

” 即时消息安全性（5）：对称性Android加密技术的应用实践” 

“即时消息安全性（第六部分）：非对称加密技术的原理和应用实践” 

“即时消息安全性（第七部分）：使用JWT技术解决IM系统套接字 长期身份认证的难点”（本文）

 4。我们面临的技术难点

对于我们的IM系统Guazi中的套接字长连接身份认证的安全性问题 具有统一的登录身份验证系统SSO（即单点登录系统，其原理在“ IM开发基础知识补充课程（1）：正确理解前端HTTP SSO单点登录接口的原理”中进行了描述）  。

我们的IM长连接通道也使用此系统进行安全认证，其结构如下：

即时消息安全性（7）：使用JWT技术解决IM系统套接字长连接身份认证的痛苦 点_1。  jpg 

如上图所示，整个身份验证步骤如下：

 1）用户登录到App，App从SSO获得SSO发行的令牌。 商业背景；  

 2）当应用需要使用IM功能时，将令牌传递给IM客户端SDK；  

 3）客户端SDK与IM Server建立长连接时，使用令牌进行身份验证；  

 4）IM Server请求SSO单点登录。系统确认令牌的有效性。  

 *补充：如果您对SSO单一登录系统了解不多，请务必阅读“ IM开发基础知识补充类（1）：正确理解前端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开发人员必须阅读的（1）：易于理解，理解“弱”和“慢”的》 移动网络“ 

”对于移动终端IM开发人员是必不可少的（2）：历史上最全面的移动弱网络优化方法摘要” 

 5，充分了解什么是JWT技术

 [h  ] 5.1基础知识

 JSON Web令牌（简称JWT）是一种开放安全的行业标准（有关详细信息，请参阅RFC7519），可用于在多个系统之间传输安全可靠的信息（包括传输身份） 本文将使用的身份验证）信息场景）

结构是什么 完整的JWT令牌字符串？  

即时消息安全性（7）：使用JWT技术解决IM系统套接字长连接的身份认证问题_20180301214817473.jpg 

▲JWT最后还是令牌字符串，它由三部分组成：头部 ，有效载荷和签名

如上图所示，JWT令牌字符串如下组成：

 1）红色为Header：指定令牌类型和签名类型；  

 2）紫色是负载（播放负载）：存储用户ID和其他关键信息；  

 3）蓝色是签名：确保整个信息的完整性和可靠性（此签名字符串等效于一个段落被添加密文的安全性由它决定。  

 5.2解密JWT的标头（Header）

 JWT的标头用于描述有关JWT的最基本信息，例如其类型和用于签名的算法 。  

这可以表示为JSON对象：

 {

“ typ”：“ JWT”，

“ alg”：“ HS256” 

} 

▲在此标头中，指示这是一个JWT字符串，并且使用的签名算法是HS256算法

 Base64对其进行编码，随后的字符串成为JWT标头（Head），即 您在第5.1节中看到的红色部分：

 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 

（您可以自己尝试进行Base64加密和解析，例如，使用此在线工具：http://tool.oschina.net/  crypto？type = 3）

 5.3解密JWT有效负载（播放负载）

可以在有效负载（播放负载）中定义以下属性：

 1）iss：发行者 智威汤逊的;  

 2）sub：JWT面向的用户；  

 3）aud：接收JWT的一方；  

 4）exp（expires）：什么时间到期，这是Unix时间戳；  

 5）iat（发布于）：发布时。  

上面的信息也可以由JSON对象描述。  Base64对上述JSON对象进行编码以获取以下字符串。  

我们将其称为JWT有效负载。 以下示例字符串是您在第5.1节中看到的紫色部分：

 eyJpc3MiOiIyOWZmMDE5OGJlOGM0YzNlYTZlZTA4YjE1MGRhNTU0NC1XRUIiLCJleHAiOjEh [M]]（您可以自己尝试Base64加密和解析，例如使用此在线工具：http://tool.oschina.net/encrypt?type=3）

 5.4解决JWT签名（签名）

 JWT签名 该部分在官方文档中的描述如下：

 HMACSHA256（

 base64UrlEncode（header）+“。” + 

 base64UrlEncode（payload），

 secret）

 上面的伪代码的含义如下：

 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIyOWZmMDE5OGJlOGM0YzNlYTZlZTA4YjE1MGRhNTU0NC1X [[H] 最后，我们使用HS256算法对上面缝合的字符串进行加密。 加密时，我们还需要提供一个秘密。  

然后，根据RFC7519中描述的方法，我们可以获得加密的内容：

 Pk-vIzxElzyzFbzR4tUxAAET8xT9EP49b7hpcPazd0 

▲这是我们需要的JWT的签名部分

  ] 

 5.5签名

的目的生成JWT令牌字符串的签名过程的最后一步实际上是对标头和有效内容进行加密。  

一般而言：不同输入的加密算法输出始终是不同的。 因此，如果有人在解码后修改标头和有效载荷的内容，然后对其进行编码，则新标头和有效载荷的签名将与先前的签名不同。 此外，如果您不知道服务器在加密时使用的密钥，那么生成的签名也会有所不同。  

换句话说：您的JWT字符串的安全强度基本上由此签名部分确定。  

使用时：服务器收到JWT令牌字符串后，将首先使用开发人员指定的秘密（可以理解为密码）对报头和有效内容进行再次签名，方法相同。 那么服务器应用程序如何知道我们使用哪种算法？ 别忘了，我们在JWT的标头中用alg字段指示了我们的加密算法。  

如果服务器以相同的方式再次签名标头和有效负载，并且发现计算出的签名和接收到的签名不相同，则意味着该令牌的内容已被其他人移动，我们 应该拒绝JWT令牌并返回HTTP 401未经授权的响应。  

 5.6一个典型的JWT应用程序过程

 JWT是什么样的过程？ 一，官方文件图：

即时通讯安全性（7）：使用JWT技术解决IM _20180301220433899.jpg 

 As系统长套接字连接身份认证的痛点 如上图所示，整个应用过程描述如下：

 1）客户端使用帐户密码请求登录界面；  

 2）登录成功后，服务器使用签名密钥生成JWT，然后将JWT返回给客户端。  

 3）客户端从服务器请求另一个接口时带来了JWT；  

 4）服务器在收到JWT后验证签名的有效性。 对客户端做出相应的响应。  

 5.7总而言之

 JWT的整个技术原理是一个非常典型的对称加密应用程序。 用外行的术语来说，它使用开发人员在服务器端保存的密码，用户的ID等。信息已加密，并且根据JWT规则将字符串返回给用户（请参阅第5.1节）。 用户在使用该字符串时会将其提交给相应的服务器。 服务器取出JWT字符串的标头信息和有效负载，尝试使用开发人员指定的密码对其进行加密，然后获取一个字符串（即合法的JWT令牌）。 比较两者（如果相同），则认为用户提交的JWT是合法的，否则不是合法的。 这就是JWT的全部原理，非常简单易懂。  

 JWT技术的价值不在于特定技术实施，但是其思想本身（特别是在异构系统和分布式系统中）可以极大地简化安全认证的成本，包括简化体系结构的复杂性，降低使用门槛等，因为JWT的技术原理决定了认证 进程不需要其他系统的参与，并且可以由当前实例本身完成，从而产生非常小的身份验证代码（只是加密字符串的比较）。  

它的技术思想已广泛应用于各种当前的开发系统中。 例如，在下图中的微信公众号的服务接口配置中，也使用了类似的思路：

即时消息安全性（七个）：使用JWT技术解决IM系统的身份验证问题套接字长连接_QQ20181127  -150738.jpg 

此外，苹果公司著名的APNs推送服务还支持JWT技术。 有关详细信息，请参阅第6.2节：

 Instant Messaging Security（7）：使用JWT技术解决以下问题：“基于APNs的最新HTTP / 2”接口，以实现iOS的高性能消息推送（服务端）。  IM系统的身份验证套接字长连接_WX20181128-095457@2x.gif 

▲上面的屏幕截图摘自Apple的官方开发人员文档

 6.我们如何使用JWT技术？

  ，我们详细了解了JWT技术的原理，然后回到本文的初衷：如何使用JWT技术解决上述共同点？

我们使用JWT验证IM Socket长连接 过程如下：

即时消息安全性（7）：使用JWT技术解决IM系统套接字长连接身份认证的痛苦point_3.jpg 

如上图所示，描述了整个验证过程 如下所示：

 1）用户登录到应用程序（  （使用IM客户服务SDK），并且该应用从业务背景接收SSO单一登录系统发布的令牌（注意：此令牌不是JWT令牌，它将在步骤3中使用）并生成一个 真正的JWT令牌）；  

 2）当应用程序需要使用IM功能时，请将令牌传递给IM客户端SDK（位于客户端完成时，即当应用程序的功能调用IM客户端SDK时； 

 3  ）IM客户端SDK将输入用户名和步骤2在该过程中获得的令牌将在后台（发出JWT令牌的模块）发送到JWT服务器，请求JWT令牌。  

 4）JWT服务器收到步骤3）中提交的令牌后，将通过RPC和其他技术Submit将技术发送到SSO系统，以验证此令牌的合法性。 如果合法，请使用与IM Server达成共识的Secret（您可以理解这只是一个固定密码），根据业务需要发行JWT令牌，最后返回IM客户端SDK（即，完成 步骤3）。  

 5）之后，IM客户端SDK将使用获得的JWT令牌来请求IM Server验证长连接。  IM Server直接使用JWT规则，而无需依赖其他系统（加上步骤4）。  JWT服务器的秘密）可以完成对jwttoken合法性的验证。  

通过上述努力，解决了移动终端在弱网络条件下频繁认证长连接的痛点。  

 7。  JWT技术的缺点

当然，我们选择JWT技术的原因主要是因为它简单易用，但是也许由于这个原因，在某种程度上，这是完全相同的。 其缺点的原因。  

 JWT技术的缺点和提出的解决方案主要是：

 1）JWT的最大缺点是服务器不保存会话状态，因此无法取消令牌 或在使用过程中更改令牌的权限。 也就是说，一旦发布JWT，它将在有效期内保持有效；  

 2）JWT本身包含身份验证信息（即，您在第5.1节中看到的标头信息和负载信息），因此一旦信息泄漏，任何人都可以获取令牌的所有权限。 为了减少盗用，JWT的有效期不应设置得太长。 对于某些重要操作，用户应在每次使用时进行身份验证；  

 3）为了减少盗窃和盗窃，JWT不建议使用HTTP协议来传输代码，而是建议使用加密的HTTPS（SSL）协议进行传输。  

以下文章列出了一些适用于JWT的应用程序场景，仅供参考：

 https：//www.jianshu。com / p / af8360b83a9f 

 8。 评论

 JWT实际上是一个更具争议性的技术。 赞美它的人会说它简单易用，成本低廉，而对其贬值的人会说它的安全性就像一层窗户纸一样，当您戳戳它会破裂。  

不可否认，与当前流行的非对称加密技术（最熟悉的HTTPS协议是典型的非对称加密应用场景）相比，JWT技术的安全系数确实相对较低，因为JWT的本质 是对称加密技术的应用，而出现非对称加密技术的原因是为了增强对称加密技术所没有的一些安全性。  

但是，非对称加密技术是如此之好，并不意味着对称加密技术是无用的，因为并非所有场景都需要使用性能，体系结构复杂性，运营和维护成本来换取高安全性，或者 句子：“足够安全”，这就是JWT技术仍然具有其价值的原因。  

尽管非对称加密技术是安全的，但从理论上讲它并非无懈可击。 这个世界上没有绝对安全的算法。 简而言之，如果它不是关键性的并且非常安全，那就足够了。 你说什么？