关于JWT中jku头签名验证逻辑的技术疑问

实验核心是通过注入JKU头让服务器从可控URL获取恶意密钥绕过JWT验证，以下聚焦JWT签名逻辑相关疑问，不展开实验细节。

相关背景 #

客户端侧 #

• 发送的JWT：client_jwt
• 发送的JKU头：client_jku（例如指向url_A或url_B）
• 发送的签名：client_sign
• 从JKU URL获取的密钥数据：key_data

服务端侧 #

• 收到JWT后，提取头、载荷、签名；计算签名server_sign并检查是否与client_sign匹配。

实验观察 #

1. 使用BurpSuite的JWT编辑插件签名：
   • 将初始JKU头"jku" : "url_A"改为"jku" : "url_B"时，client_sign会变化；
   • 修改key_data时，client_sign无变化。
2. 向服务器发送client_jwt：
   • 使用初始正确的key_data时，服务器返回200 OK；
   • 修改初始正确的key_data后，服务器返回401 Unauthorized。

困惑与问题 #

我原本以为客户端签名client_sign是从JKU URL获取key_data后计算的（因其中包含密钥），但实际client_sign仅依赖原始头/载荷（包括JKU值），与获取的key_data无关；而服务器却使用该URL中的key_data验证签名（依据观察2，修改key_data会返回401）。

问题：当客户端签名仅基于JKU URL字符串，而服务器依赖该URL的实际key_data时，服务器是如何验证client_jwt的？

内容的提问来源于stack exchange，提问作者David Adonis