这可能是基于个人意见的,但我仍然想知道是否有最佳实践,因为我对WebSocket实践几乎一无所知。
我有一个单页应用程序(SPA),从我的自己的OP(OpenID Provider)获取JWT令牌。然后使用该JWT连接到我拥有的其他服务,使用REST和WebSockets。
就REST而言,非常简单:
- REST API验证JWT(发送在"Authorization: Bearer..."中),提供对受保护资源的访问或响应401,让SPA知道它需要请求新的令牌。
现在考虑WebSockets:
- 在SPA加载期间,一旦获得令牌,我就会打开到我的WebService的WS。我发送的第一条消息是具有我的JWT的登录消息,然后我在服务器的websocket实例上保存此JWT以知道谁正在发送消息。 - 我接收到每个子消息时都会验证JWT是否过期。一旦过期,我理解有两个选择:
1. 使用某种“token_expired”错误丢弃websocket,并强制浏览器在刷新令牌后重新建立websocket连接。 2. 保持websocket打开,返回错误消息并发送一个新的登录消息(一旦刷新令牌)。 3. 不使用登录消息,而只是在每个请求中发送JWT。
问题:你会推荐哪种方法?在安全性和性能方面有何考虑?还有其他未列出的常见做法吗?
我有一个单页应用程序(SPA),从我的自己的OP(OpenID Provider)获取JWT令牌。然后使用该JWT连接到我拥有的其他服务,使用REST和WebSockets。
就REST而言,非常简单:
- REST API验证JWT(发送在"Authorization: Bearer..."中),提供对受保护资源的访问或响应401,让SPA知道它需要请求新的令牌。
现在考虑WebSockets:
- 在SPA加载期间,一旦获得令牌,我就会打开到我的WebService的WS。我发送的第一条消息是具有我的JWT的登录消息,然后我在服务器的websocket实例上保存此JWT以知道谁正在发送消息。 - 我接收到每个子消息时都会验证JWT是否过期。一旦过期,我理解有两个选择:
1. 使用某种“token_expired”错误丢弃websocket,并强制浏览器在刷新令牌后重新建立websocket连接。 2. 保持websocket打开,返回错误消息并发送一个新的登录消息(一旦刷新令牌)。 3. 不使用登录消息,而只是在每个请求中发送JWT。
问题:你会推荐哪种方法?在安全性和性能方面有何考虑?还有其他未列出的常见做法吗?
OP
是什么意思? #2 经典的方法是用用户/密码交换获取新的 JWT。那么,“我发送的第一条消息是带有我的 JWT 的登录消息”是什么意思? - JRichardszOP
指 OpenID 提供者。当时我们尝试使用 JWT 进行 WebSocket 的身份验证,而不会打扰用户输入他的凭据,无论是通过在服务器端实现还是通过放弃 WebSocket 并使用刷新后的 JWT 进行重新授权。我将在一两天内详细分享我们想出的做法,因为对这个问题产生了如此浓厚的兴趣。虽然 REST 很容易处理,但 WS 保持套接字开启,因此需要处理仍然保持开启状态的套接字过期的情况。 - mati.o