为什么 JWT 签名对于特定有效负载不是唯一的答案

【问题标题】：Why is a JWT signature not unique for a specific payload为什么 JWT 签名对于特定有效负载不是唯一的
【发布时间】：2016-07-21 15:36:52
【问题描述】：

我的应用程序正在使用 JWT，应该可以防止重放攻击。我正在测试这个并遇到了以下问题。

当我拥有有效的 JWT 并更改令牌/签名的最后一个字符时，JWT 仍然有效。例如。以下令牌都正确验证： eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r4 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r5 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r6 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r7

我已经在http://jwt.io/ 上检查了这一点，并且也可以在我的 .Net 应用程序中复制。

有人可以解释为什么签名对于给定的有效负载不是唯一的吗？我知道可能会发生冲突，但我无法解释它们是连续的序列。

【问题讨论】：

标签： base64 digital-signature jwt hmac

【解决方案1】：

在这种特殊情况下您正在更改签名的 base64 url 编码，而不是签名本身

第四个 base64 值编码相同的二进制值。尝试在http://kjur.github.io/jsjws/tool_b64udec.html 处转换为十六进制

你会看到的值是

52415848aee14927a2a9439231d6d781b384acc167b8ad049a4d7bdb69f2fabe

如果您将后缀更改为-r1 或-r8，则二进制值更改并且签名验证将失败

Can two different BASE 64 encoded strings result into same string if decoded?

【讨论】：

【解决方案2】：

当您更改签名（最后一部分）时，您仍然可以解码 JWT 以查看标头和有效负载。但是，如果您尝试使用更改的签名验证 JWT，该验证将失败。

【讨论】：

这不是真的。因为你改变了签名。签名本身显然不是签名本身的一部分。因此，您可以更改签名并仍然有有效的消息。这就是整个问题的意义所在。显然，这是 base64 的行为方式所固有的。这意味着您有不同的令牌，具有完全相同的有效负载和不同的签名，但都是有效的。
我不明白“您仍然可以收到有效的消息”。是的，您仍然可以“解码”JwtHeader 和 JwtPayload，但验证 JWT 的过程需要确保“签名”与 JwtHeader 和 JwtPayload 匹配。所以不，JWT 不会被认为是有效的，图书馆应该拒绝它。