这实际上可以分解为很多单独的问题来理解整个过程。
1. 据我所知,JWT只是将三个JSON对象分别编码为base64。然后这些Base64字符串由句点分隔。这纯粹是为了“更短的消息”吗?
2. 这些包括标头、“有效负载”和签名。标头和有效负载对任何拦截它们的人都是100%可读的。它们只是可以解码成JSON并阅读的base64字符串。
3. 然后是关键的部分:服务器接收到无法解码的SIGNATURE。签名实际上是标头、有效负载和一个密钥的哈希值。因此,服务器获取标头、有效负载和自己的密钥,并生成哈希值。如果此哈希值与消息一起发送的签名匹配,则信任该消息。如果签名不匹配,则消息无效。
我的问题是什么?这里有两个单独的密钥在哪里?似乎用于加密消息和解密消息的密钥相同。这是我的问题的根源——如果您没有回答其他问题,请帮助解决此问题。
除此之外,我想知道是否正确理解了整个过程?还有,“协商公共密钥”然后交换“公钥/私钥混合物”的标准在哪里?我只看到相同的密钥用于编码/解码。但是协商是何时发生的?顺便提一下,这是在.NET和Auth0中查看的,但是总的来说是一个问题。
随机资料,如果有人以后感兴趣:
JWT摘要:https://scotch.io/tutorials/the-anatomy-of-a-json-web-token 公钥/非对称加密:https://youtu.be/3QnD2c4Xovk 哈希:http://www.webopedia.com/TERM/H/hashing.html Base64:http://en.wikipedia.org/wiki/Base64
1. 据我所知,JWT只是将三个JSON对象分别编码为base64。然后这些Base64字符串由句点分隔。这纯粹是为了“更短的消息”吗?
2. 这些包括标头、“有效负载”和签名。标头和有效负载对任何拦截它们的人都是100%可读的。它们只是可以解码成JSON并阅读的base64字符串。
3. 然后是关键的部分:服务器接收到无法解码的SIGNATURE。签名实际上是标头、有效负载和一个密钥的哈希值。因此,服务器获取标头、有效负载和自己的密钥,并生成哈希值。如果此哈希值与消息一起发送的签名匹配,则信任该消息。如果签名不匹配,则消息无效。
我的问题是什么?这里有两个单独的密钥在哪里?似乎用于加密消息和解密消息的密钥相同。这是我的问题的根源——如果您没有回答其他问题,请帮助解决此问题。
除此之外,我想知道是否正确理解了整个过程?还有,“协商公共密钥”然后交换“公钥/私钥混合物”的标准在哪里?我只看到相同的密钥用于编码/解码。但是协商是何时发生的?顺便提一下,这是在.NET和Auth0中查看的,但是总的来说是一个问题。
随机资料,如果有人以后感兴趣:
JWT摘要:https://scotch.io/tutorials/the-anatomy-of-a-json-web-token 公钥/非对称加密:https://youtu.be/3QnD2c4Xovk 哈希:http://www.webopedia.com/TERM/H/hashing.html Base64:http://en.wikipedia.org/wiki/Base64