JWT技术解决IM系统的认证痛点

一、痛点

随着业务的发展，多个业务线接入了IM系统，IM系统长连接的安全问题变得很重要。

瓜子有统一登录认证系统SSO，IM长连接通道也利用这个系统做安全认证，结构如下图。 

认证步骤如下

用户登录App，App从业务后台拿到单点系统SSO颁发的token

当App需要使用IM功能时，将token传给IM客服端SDK

SDK跟IM Server建立长连接的时候用token进行认证

IM Server请求SSO系统，确认token合法性

咋一看，这个过程没有什么问题，但是IM（尤其是移动IM）业务的特殊性，这个结构并不好。

手机（移动端）网络很不稳定，进出地铁可能断网，挪动位置也可能换基站。在一次聊天过程中，会经常重新建立长连接，第3步会被频繁执行，进而第4步也会频繁执行。（1）大大增加了SSO系统的压力；（2）较长的链路带来的延迟对用户的体验是一种伤害（SSO系统也可能短暂开小差）。

如果不通过第4步就能完成验证，那这个痛点会得到极大缓解。我们想到了JWT技术。

二、什么是JWT？

官网上是这么定义JWT的。JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，可以在各方之间通过JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。 JWT可以使用密码（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。

JWT能做什么？

授权（Authorization）

这是JWT最常见的使用场景。一旦用户登录，后续每个请求将带上JWT，就可以访问该令牌（token）允许的路由，服务和资源。

JWT现在广泛应用于单点登录，它开销很小，并且能够轻松跨域。

信息交换（Information Exchange）

JWT是在各方之间安全传输信息的好方法。因为JWT可以签名（使用公钥/私钥对，签名原理参看《你的HTTP接口签名校验做对了吗？》）

您可以确定发件人的真实身份。此外，由于使用标头和payload计算签名，您还可以验证内容是否未被篡改。

JWT数据结构

JWT包含了使用“.”分隔的三部分： Header 头部 Payload 负载 Signature 签名 

Header

在header中通常包含了两部分：token类型和采用的加密算法。{ "alg": "HS256", "typ": "JWT"} 接下来对这部分内容使用 Base64Url 编码组成了JWT结构的第一部分。

Payload

Token的第二部分是负载，它包含了claim， claim是一些实体（通常指的用户）的状态和额外的元数据，有三种类型的claim：reserved, public 和 private.

Signature

Signature是对header和payload两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。

更多关于JWT的资料参看

https://jwt.io/introduction/

三、怎么做验证

采用JWT验证长连接的流程如下 

用户登录App，App从业务后台拿到单点系统SSO颁发的token

当App需要使用IM功能时，将token传给IM客服端SDK

SDK将用户名及第2步中得到的token发给后台的JWT Server（签发jwttoken的模块），请求jwttoken。

JWT Server通过SSO系统验证token的合法性，如果合法，用跟IM Server约定的公钥/私钥（或用对称加密），根据业务需要签发jwttoken，返回给IM Client SDK。

IM Client SDK使用得到的jwttoken请求IM Server验证长连接。IM Server根据约定的算法（不依赖其他系统）即可完成jwttoken合法性验证。

频繁建立长连接的验证痛点得到解决。

四、缺点

JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。

JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。

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

以下这个地址的文章写了一些适用JWT的场景

https://www.jianshu.com/p/af8360b83a9f