Question

我没有找到现有答案的事实让我觉得我问的是错误的问题。如果有必要，请随意（轻轻地或以其他方式）推动我走上更好的道路。

我们使用专用的auth服务器，其目的是（1）给定登录凭据，根据一组规则返回给定JWT的近期exp或（2）的JWT ，发布一个新的JWT。基本上刷新。

这一切都有效，直到它被黑了。但就目前而言，它是王牌。

然而，当涉及socket.io与非身份验证服务器的连接时，我们的拍摄时间不止于此。我想知道是否会有人评价这个过程。（我很高兴发布更多代码;你告诉我它是否相关）。

1）初始socket.io连接导致挑战：

this.socket.emit('authenticate'); // the challenge

this.authTimeout = setTimeout(() => {
  this.socket.disconnect('unauthorized', errors);
}, TIME_TO_AUTHENTICATE); // the response kills this!

this.socket.on('authenticate', token => {
  clearTimeout(this.authTimeout);
  this._authenticate(token)
})

2）后续消息必须包含以下形式的“payload”消息： payload = {token: 'foo', message: 'bar'}，如果有效则接受哪个令牌，如果无效则返回。

此外，资源服务器发送自己的定期heartbeat，必须由heartbeat {token}确认。

我的问题是：这似乎太容易了;我在哪儿偷工减料？你能否打败这种虚弱的防御工事？

为了清楚起见，我们希望在这里推出自己的模块。我很高兴看到现有的东西;只是没有发现任何我可以开始说服老板完全满足我们的需求。

非常感谢提前。

Answer 1

我无法完全分析方法或确保它没有瑕疵，但我想指出一些想到的事情：

除了在身份验证质询超时的情况下断开用户连接之外，您还必须确保服务器在实际成功完成授权质询之后才向该用户发送任何非公开消息。否则，有一段时间直到超时，用户可以在未经过身份验证的情况下收到消息。
我认为如果令牌无效（或者某种情况阻止发送非公开消息），你也会断开套接字。
This article是关于使用JWT验证socket.io通信。它是从2014年开始的，所以它可能有点过时，但我认为核心概念仍然有效。
与本文相关，有一个专门用于使用jwt验证socket.io连接的工具。即使您不想使用它，您也可能希望探索其代码以寻找＆＃34;灵感＆＃34;。你可以在这里找到它：socketio-jwt。

您可以看到此工具可以使用两种不同的方法：

与您的方法非常类似的方法：

来自socketio-jwt / blob / master / lib / index.js

if(options.required){
  var auth_timeout = setTimeout(function () {
    socket.disconnect('unauthorized');
  }, options.timeout || 5000);
}

socket.on('authenticate', function (data) {
  // ...
  // Token validation

  // Emit "authenticated" event if token is valid, the server can use
  // this event as a point to send messages, once token is valid
});

A＆＃34;一次往返＆＃34;在握手期间基本上使用查询字符串的方法其主要缺点是令牌暴露在URL中，因此可能会被记录或暴露。

通过Socket.io连接进行JWT授权

1 个答案: