基于Token认证的WebSocket连接概要认证的方式（cookie or Token）基于Token的认证

WebSocket作为一种支持浏览器与服务器全双工通信的协议，对于复杂的前端应用，在交互体验和性能的改进上，是一种非常合适的解决方案。随着WebSocket更多地应用于生产开发，安全也成为了必须要关注的问题。

关于安全有一个可能的误区是：如果用户通过了web应用的认证（登录了系统），建立的WebSocket连接，就也是经过认证的。实际上，这是两个完全不同的通道，socket连接需要建立自己的认证体系。

有两种方式可以解决认证的问题，一种是传统的基于cookie，一种是基于Token的。

两种方式比较起来，个人更倾向于基于Token的方案。主要是以下几方面考虑：

耦合性。基于cookie，意味着，应用本身的认证和提供WebSocket的服务，得是同一套session cookie的管理机制。有的时候，可能这也不是大的问题，但是以目前我们工程中的大部分场景看，应用服务是基于java的一些web framework，而socket由Socket.IO来提供。让两个功能的系统协调一种共享的认证方式，就不那么容易。所以，需要解除这种对应用服务的依赖。

session的管理。同时，如果WebSocket服务自己来维护基于cookie的认证，就需要借助一些存储（DB、Redis）来存储session。作为一个纯为解决通信连接的服务，这一块也是不希望来维护的。

适用性。另外，cookie也会在有些设备或浏览器设置中被禁用，在这种情况下，就还需要一种替代的方式来实现认证。这一点上，cookie也是不如基于Token的。

以下是一个简单的例子，基于express、Socket.IO来构建了一个支持认证的WebScoket通信服务。

其中，用到了两个实现库：

<a href="https://github.com/auth0/node-jsonwebtoken">jsonwebtoken</a>

<a href="https://github.com/auth0/socketio-jwt">socketio-jwt</a>

应用服务模块，在用户登录的时候创建一个token，

在Socket.IO模块，绑定一个全局的回调用来做认证。

其中，jwtSecret需要保存在服务器上，用来完成JWT的验证。

如果客户单发送了有效的JWT，相当于握手成功并且connection就会建立。

以下是一个简单的客户端例子：

相比较基于cookie，基于token的方式非常易于代码实现，且便于集成到已有系统中。