4

这实际上分解为许多单独的问题以了解整个过程。

  1. 据我了解，JWT 只是三个 JSON 对象，它们彼此分开编码为 base64。然后 Base64 字符串用句点分隔。这纯粹是为了“短消息”的目的吗？

  2. 这些包括标题、“有效负载”和签名。任何拦截它们的人都可以 100% 地读取标头和有效负载。它们只是可以解码为 JSON 并读取的 base64 字符串。

  3. 然后 MAGIC：服务器收到无法解码的 SIGNATURE。签名实际上是标头、有效负载和密钥的散列。因此，服务器获取标头、有效负载和 ITS OWN 密钥，并进行哈希处理。如果此哈希与消息附带的签名匹配，则该消息是可信的。如果签名不匹配，则消息无效。

我对这一切有什么问题吗？这里的两个单独的键在哪里？似乎用于加密消息的密钥和用于解密消息的密钥是相同的。这是我问题的根源——如果你什么都不回答，请帮忙。

除此之外，我想知道我是否正确理解了这个过程？此外，“同意公钥”的标准在哪里，然后在这里发生公钥/私钥的“混合”交易？我所看到的只是用于编码/解码的相同密钥。但是协议是什么时候发生的呢？在 .NET 和 Auth0 btw 的上下文中查看此内容，但总体而言是 q。

如果有人有兴趣稍后看到这个 q，我观看/阅读/使用的随机内容：

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

4

2 回答 2

3

首先，JSON 对象签名和加密标准 (JOSE) 使用 base64url 编码，而不是直接的 base64 编码，略有不同。

  1. JWT 标头和有效负载是 JSON 对象，但签名不是，这是一个 base64url 编码的二进制 blob

  2. 拦截它的任何人都可以使用整个 JWT，它的所有 3 个部分

  3. 您正在描述一种对称密钥算法，其中发送者和接收者使用相同的共享密钥；这只是 JWTS 的一种选择，另一种选择是使用公钥/私钥对进行签名/验证/加密/解密

与所有加密货币一样，密钥协议需要在带外进行。

于 2015-05-25T19:03:48.613 回答
3
  1. 然后 MAGIC：服务器收到无法解码的 SIGNATURE。签名实际上是标头、有效负载和密钥的散列。因此，服务器获取标头、有效负载和 ITS OWN 密钥，并进行哈希处理。如果此哈希与消息附带的签名匹配，则该消息是可信的。如果签名不匹配，则消息无效。

这里没有魔法。JWT 支持四种众所周知的签名和 MAC（消息验证码）结构：HMAC（一种对称算法），以及 ECDSA、RSASSA-PKCS-v1.5 和 RSASSA-PSS（公钥算法）。这些中的每一个都可以与 SHA-256、SHA-384 或 SHA-512 加密摘要一起使用。另请参阅RFC 7518 - JSON Web Algorithms (JWA)中的数字签名和 MAC 加密算法表。

我对这一切有什么问题吗？这里的两个单独的键在哪里？似乎用于加密消息的密钥和用于解密消息的密钥是相同的。这是我问题的根源——如果你什么都不回答，请帮忙。

不一定有两个单独的密钥 - 如果使用公钥算法，将使用服务器的私钥创建签名，并使用相应的公钥进行验证。但如果使用 HMAC 算法，则必须使用共享密钥进行签名和验证。

于 2015-05-26T01:21:02.107 回答