JWT 如何实现公钥加密？

Question

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

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

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

3. 然后MAGIC：服务器收到无法解码的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

Answer 1

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

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

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

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

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