续订WebSocket连接的令牌的最佳做法是什么？

Question

这可能是基于意见的,但我仍然怀疑是否有最佳实践,因为我对websocket实践几乎一无所知

我有一个从我自己获得JWT令牌的SPA OP.然后它使用该JWT连接到我使用REST和WebSockets的其他服务.

就REST来说,它非常简单:

• REST API验证JWT(已发送Authorization: Bearer ...)并提供对受保护资源的访问,或者使用a响应401,让SPA知道它需要请求新令牌.

现在有websockets:

在加载SPA期间,一旦我获得了令牌,我就打开了一个WS到我的web服务.我发送的第一条消息是login_message我的JWT,然后我保留在服务器的websocket实例上以了解谁在发送消息.我收到的每个后续消息,我都会验证JWT是否已过期.

据我所知,一旦它到期,我面临两个选择:

1. 删除websocket时会token_expired出现某种错误,并在令牌刷新后强制浏览器建立新的websocket连接.

2. 保持websocket打开,返回错误消息并发送新的登录消息(刷新​​令牌后)

3. 不要使用登录消息,只需在每个请求中发送JWT.

问题:您会推荐哪种方法？为什么？在安全性和性能方面.我没有列出其他常见做法吗？

Answer 1

我问过一个很老的问题，所以我很乐意分享我们选择的做法：

1. 一旦客户得到他的JWT第一次获取他的数据（当应用程序启动时），就会打开一个 WebSocket。

2. 为了验证通道，我们发送一条我们定义为协议一部分的消息，称为authMessage该消息，其中包含以下内容JWT。

3. 服务器将此数据存储在套接字的实例上，并在沿线发送数据或从客户端接收数据之前验证其有效性/到期时间。

4. 令牌在过期前几分钟会在 Web 应用程序中静默刷新，然后再过几分钟authMessage服务器发出另一个令牌（从步骤 2 开始重复）。

5. 如果出于某种原因它在更新之前过期，服务器将关闭该套接字。

这大致就是我们在应用程序中实现的（未经优化）并且对我们来说效果非常好。