我正在研究CyberSource REST API,并想测试JSON Web令牌认证方法,如此处记录:https://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html
我无法复制“ JWT有效负载/声明集”部分中描述的JSON有效负载的sha256哈希。
{
"clientReferenceInformation" : {
"code" : "TC50171_3"
},
"orderInformation" : {
"amountDetails" : {
"totalAmount" : "102.21",
"currency" : "USD"
}
}
}
我试图在包含有效负载示例的文件上以二进制和文本格式使用sha256sum命令。我还尝试在此有效负载的不同排列上运行此命令,例如不带空格或换行符。
我希望得到示例哈希值
2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c
但是得到
f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3
和其他不同的哈希值。
我在做什么错了?
答案 0 :(得分:0)
可能您没有做错任何事情。哈希函数具有avalanche effect,其中输入中的任何不同位都会改变输出哈希。如果该站点的原始示例使用了不同的编码,或者JSON元素使用了不同的顺序,或者甚至具有或多或少的制表符,空格,换行符或任何其他“垃圾”字符,那么您将很难找到该网站上显示的哈希值的合适消息。
通常,密码解决方案使用规范化来避免此类问题(语义相等的消息使用不同的哈希值)。但是,JWT specification没有为JSON指定任何类型的规范化。
简而言之,我认为您不必为此担心。只要您使用有效的(正确实现的)哈希函数,您的JWT实现都是正确的。
此外,我注意到JWT specification没有为JWT有效负载指定“摘要”字段。因此,您甚至不需要使用此字段。除非CyberSource REST API使其为强制性。
答案 1 :(得分:0)
由于所谓的“示例”哈希包含33个十六进制字符,因此可以看出它不是SHA256的有效输出。因此,您无能为力以使自己的示例与他们的示例相匹配。
该讨论中还有一个base64示例,但它也不是有效的base64。通过在base64上添加额外的填充字符'='可以使其有效,并对其进行解码后发现,该字符大部分与所谓的SHA256哈希匹配。
我的猜测是该页面上的值只是人眼看起来像什么的示例,而不是您应该精确匹配的测试向量。