2

互联网上有很多关于 JsonWebTokens 的信息，但关于使用它对 HTTP 消息的内容进行签名的信息并不多。

所以它可以签署自己的声明，但我不清楚是否有标准方式（和可用的实现）让它携带消息正文的签名（至少，HTTP 标头下方的任何内容）。

这是最重要的，因为如果另一个客户端自己窃取了令牌，它可能会被用来制作非合法请求，直到它过期。

这是迄今为止我找到的关于该主题的唯一资源：API Message Integrity With JSON Web Token (JWT)。标题很有希望，但文章并没有真正说明如何去做，它只是表明了这样做的兴趣。

顺便说一下，如果可以对正文的内容进行签名，那么签名验证的快速失败实现会很棒，例如分段的（例如，如果立即丢弃消息识别前 10kB 已被篡改，而不必摄取整个 10MB 消息）。

更多细节

我知道 JWT 是一个令牌，因此常见的用法是让授权方将令牌传递给客户端，然后客户端将在其请求中透明地将其转发给服务器。因此，身份验证方不知道客户端接下来会执行什么实际请求，并且无法签署此类请求的内容（这也是不切实际的，应该为每个请求发出不同的“令牌”）。它只是将令牌提供给客户端，客户端将不加更改地将令牌附加到每个请求。

但我认为在现实世界中的某些情况下，JWT 也是由客户端自己（而不是第三方）生成的，这意味着客户端知道共享密钥，并为自己合法地签署请求。
在这种情况下，原则上客户端可以签署 http 正文的内容，而不仅仅是 JWT 令牌的内容。
总而言之，我怀疑 JWT 格式不适合这种签名。客户端和服务器应该定义自己的协议/格式来做到这一点。

4

1 回答 1

0

免责声明：我绝不是安全专家。

JWT 的工作不是对请求正文的内容进行签名，而是向接收服务提供有关 JWT 的来源及其包含的声明的可验证信息。因此，当您的服务收到 JWT 时，您可以验证它的部分或全部重要方面：

  • 非对称签名的公钥
  • 发行人
  • 观众
  • 到期

等等。

至于如何确保请求的内容是它声称的内容，这是TLS传输层安全的工作。TLS 握手过程是发送和接收服务器本质上相互了解、验证每个服务器是否值得信赖并生成自己的非对称密钥集（每个会话！）以加密它们之间的流量的地方。

因此，TLS 的重点是确保由一个受信任源发送的数据完整（并加密）到达另一个可以解密的受信任源。虽然不完全是您询问的机制，但我相信它可以达到目标。

于 2019-10-11T20:58:36.377 回答