根据 JWT RFC，JWT 可以选择拥有一个 JTI，我将其解释为 JWT 的唯一 ID。似乎 UUID 对 JTI 来说是一个很好的价值。RFC 声称 JTI 可用于防止 JWT 被重放。两个问题：
“jti”（JWT ID）声明为 JWT 提供了唯一标识符。
标识符值的分配方式必须确保相同的值被 意外分配给不同的数据对象
的可能性可以忽略不计；
如果应用程序
使用多个发行者，则必须防止
不同发行者产生的值之间的冲突。“jti”声明可用于
防止 JWT 被重放。“jti”值是
区分大小写的字符串。使用此声明是可选的。
- JTI 如何防止 JWT 被重放？
- JTI 字段应该多久重新生成一次？对每一个要求？还是仅在生成新令牌时？
我相信这两个问题的答案将取决于应用程序本身。
例如，如果它已被编程为仅接收具有唯一 JTI 的消息，则应用程序可以忽略相同 JTI 的重播。
在这种情况下，当重复相同的消息有效时，将重新生成 JTI。
好问题。我认为 RFC 文本有点混乱。
如果 JWT 在某些 API 调用中被截获，那么这个令牌当然可以反复使用（除非应用程序创建一次性 JWT，但这违背了 JWT 的目的）。这不是 JTI 防御的那种“重放攻击”。
加密随机数“只能使用一次”，因此它只是一个随机数，不应该在两个单独的 JWT 合成中使用。他们更喜欢 TLS 证书序列号。
我想说 JTI 让 API 开发人员更容易做两件事：
我认为应用程序应该具有某种存储实现，以便将 JWT 令牌与服务器已收到的现有 JTI 进行交叉检查。
存储实现可以是一个缓存存储器，其中将存储已使用的 JTI 值。而且此验证有权到期时间，因此不需要更大的存储空间来存储 JTI 的。
保存在缓存中的 JTI ID 会根据任何新的传入 JTI ID 检查。除非缓存已满，否则不会丢弃存储在缓存中的 JTI ID。
请参阅以下链接了解更多信息： https ://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/cwlp_jwttoken.html