我爱JWT . 合作真的很有趣 . 我的问题是：如果我得到JWT并且我可以解码有效载荷，那么它是如何安全的？我不能只是从 Headers 中获取令牌，解码并更改有效负载中的用户信息，并使用相同的正确编码密码将其发回？
我知道他们必须是安全的，但我真的很想了解这些技术 . 我错过了什么？谢谢！
JWT可以是签名，加密或两者兼而有之 . 如果令牌已签名但未加密，则每个人都可以读取令牌的内容，但是当您不知道私钥时，您无法更改它 . 否则，接收方将注意到签名将不再匹配 .
回答你的评论：我不确定我是否以正确的方式理解你的评论 . 只是为了确定：你知道并理解数字签名吗？我将简要解释一个变体（HMAC，它是对称的，但还有很多其他变体） .
让's assume Alice wants to send a JWT to Bob. They both know some shared secret. Mallory doesn'知道这个秘密，但想要干涉并改变JWT . 为了防止这种情况，Alice计算 Hash(payload + secret) 并将其作为签名附加 .
Hash(payload + secret)
收到消息时，Bob还可以计算 Hash(payload + secret) 以检查签名是否匹配 . 但是，如果Mallory更改了内容中的某些内容，则无法计算匹配的签名（这将是 Hash(newContent + secret) ） . 她再也没有比赛了，鲍勃再也不会接受JWT了 .
Hash(newContent + secret)
我们假设，我向另一个人发送消息 {"id":1} 并用 Hash(content + secret) 签名 . （这里只是连接） . 我使用SHA256哈希函数，我得到的签名是： 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c . 现在轮到你了：扮演Mallory的角色并尝试签署消息 {"id":2} . 你可以't because you don't知道我用过的秘密 . 如果我认为收件人知道秘密，他可以计算任何邮件的签名并检查它是否正确 .
{"id":1}
Hash(content + secret)
330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c
{"id":2}
您可以转到jwt.io，粘贴您的令牌并阅读内容 . 这对最初的很多人来说都很不利 .
简短的回答是JWT不关心加密 . 它关心验证 . 也就是说，它总能得到“让这个令牌的内容被操纵”的答案？这意味着用户操纵JWT令牌是徒劳的，因为服务器将知道并忽略令牌 . 在向客户端发出令牌时，服务器会根据有效负载添加签名 . 稍后它会验证有效负载和匹配签名 .
逻辑问题是不加密内容的动机是什么？
最简单的原因是因为它假设这在很大程度上是一个已解决的问题 . 例如，如果处理类似Web浏览器的客户端，则可以将JWT令牌存储在 secure + httpsOnly （可以通过HTTP读取）的cookie中，并通过加密通道（HTTPS）与服务器通信 . 一旦您知道服务器和客户端之间有安全通道，就可以安全地交换JWT或其他任何您想要的东西 .
secure + httpsOnly
这样可以保持简单 . 一个简单的实现使得采用更容易，但它也让每个层都做它最擅长的事情（让HTTPS处理加密） .
JWT并不意味着存储敏感数据 . 一旦服务器收到JWT令牌并对其进行验证，就可以在其自己的数据库中查找用户ID，以获取该用户的其他信息（如权限，邮政地址等） . 这使JWT的尺寸变小，避免了无意中的信息泄漏，因为每个人都知道不要在JWT中保留敏感数据 .
它与 Cookies 本身的工作方式并无太大差别 . Cookie通常包含未加密的有效负载 . 如果您使用HTTPS，那么一切都很好 . 如果您不是，那么建议您自己加密敏感cookie . 不这样做意味着可能发生中间人攻击 - 代理服务器或ISP读取cookie，然后假装是你，然后重放它们 . 出于类似的原因，JWT应始终通过HTTPS等安全层进行交换 .
json Web令牌（JWT）中的内容本身并不安全，但有一个用于验证令牌真实性的内置功能 . JWT是由句点分隔的三个哈希 . 第三是签名 . 在公钥/私钥系统中，发行者使用私钥对令牌签名进行签名，该私钥只能通过其对应的公钥进行验证 .
理解发行者和验证者之间的区别非常重要 . 令牌的收件人是负责验证它 .
在Web应用程序中安全地使用JWT有两个关键步骤：1）通过加密通道发送它们，以及2）在收到签名后立即验证签名 . 公钥加密的非对称性使得JWT签名验证成为可能 . 公钥验证JWT是否由其匹配的私钥签名 . 没有其他密钥组合可以执行此验证，从而防止模拟尝试 . 按照这两个步骤，我们可以保证数学上确定JWT的真实性 .
更多阅读：How does a public key verify a signature?
只有JWT的privateKey，它在您的服务器上将解密加密的JWT . 知道privateKey的人将能够解密加密的JWT .
将privateKey隐藏在服务器的安全位置，永远不要告诉任何人privateKey .
JWT中的数据经过签名和加密，并不意味着它是安全的 . JWT不为敏感数据提供保证 .
使用私钥（即发送方和接收方都知道的私钥）对数据进行加密，入侵者可以制作密钥并且可以改变内容 .
据我所知，JWT不提供安全性 .
谢谢
5 回答
JWT可以是签名，加密或两者兼而有之 . 如果令牌已签名但未加密，则每个人都可以读取令牌的内容，但是当您不知道私钥时，您无法更改它 . 否则，接收方将注意到签名将不再匹配 .
回答你的评论：我不确定我是否以正确的方式理解你的评论 . 只是为了确定：你知道并理解数字签名吗？我将简要解释一个变体（HMAC，它是对称的，但还有很多其他变体） .
让's assume Alice wants to send a JWT to Bob. They both know some shared secret. Mallory doesn'知道这个秘密，但想要干涉并改变JWT . 为了防止这种情况，Alice计算
Hash(payload + secret)并将其作为签名附加 .收到消息时，Bob还可以计算
Hash(payload + secret)以检查签名是否匹配 . 但是，如果Mallory更改了内容中的某些内容，则无法计算匹配的签名（这将是Hash(newContent + secret)） . 她再也没有比赛了，鲍勃再也不会接受JWT了 .我们假设，我向另一个人发送消息
{"id":1}并用Hash(content + secret)签名 . （这里只是连接） . 我使用SHA256哈希函数，我得到的签名是：330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. 现在轮到你了：扮演Mallory的角色并尝试签署消息{"id":2}. 你可以't because you don't知道我用过的秘密 . 如果我认为收件人知道秘密，他可以计算任何邮件的签名并检查它是否正确 .您可以转到jwt.io，粘贴您的令牌并阅读内容 . 这对最初的很多人来说都很不利 .
简短的回答是JWT不关心加密 . 它关心验证 . 也就是说，它总能得到“让这个令牌的内容被操纵”的答案？这意味着用户操纵JWT令牌是徒劳的，因为服务器将知道并忽略令牌 . 在向客户端发出令牌时，服务器会根据有效负载添加签名 . 稍后它会验证有效负载和匹配签名 .
逻辑问题是不加密内容的动机是什么？
最简单的原因是因为它假设这在很大程度上是一个已解决的问题 . 例如，如果处理类似Web浏览器的客户端，则可以将JWT令牌存储在
secure + httpsOnly（可以通过HTTP读取）的cookie中，并通过加密通道（HTTPS）与服务器通信 . 一旦您知道服务器和客户端之间有安全通道，就可以安全地交换JWT或其他任何您想要的东西 .这样可以保持简单 . 一个简单的实现使得采用更容易，但它也让每个层都做它最擅长的事情（让HTTPS处理加密） .
JWT并不意味着存储敏感数据 . 一旦服务器收到JWT令牌并对其进行验证，就可以在其自己的数据库中查找用户ID，以获取该用户的其他信息（如权限，邮政地址等） . 这使JWT的尺寸变小，避免了无意中的信息泄漏，因为每个人都知道不要在JWT中保留敏感数据 .
它与 Cookies 本身的工作方式并无太大差别 . Cookie通常包含未加密的有效负载 . 如果您使用HTTPS，那么一切都很好 . 如果您不是，那么建议您自己加密敏感cookie . 不这样做意味着可能发生中间人攻击 - 代理服务器或ISP读取cookie，然后假装是你，然后重放它们 . 出于类似的原因，JWT应始终通过HTTPS等安全层进行交换 .
json Web令牌（JWT）中的内容本身并不安全，但有一个用于验证令牌真实性的内置功能 . JWT是由句点分隔的三个哈希 . 第三是签名 . 在公钥/私钥系统中，发行者使用私钥对令牌签名进行签名，该私钥只能通过其对应的公钥进行验证 .
理解发行者和验证者之间的区别非常重要 . 令牌的收件人是负责验证它 .
在Web应用程序中安全地使用JWT有两个关键步骤：1）通过加密通道发送它们，以及2）在收到签名后立即验证签名 . 公钥加密的非对称性使得JWT签名验证成为可能 . 公钥验证JWT是否由其匹配的私钥签名 . 没有其他密钥组合可以执行此验证，从而防止模拟尝试 . 按照这两个步骤，我们可以保证数学上确定JWT的真实性 .
更多阅读：How does a public key verify a signature?
只有JWT的privateKey，它在您的服务器上将解密加密的JWT . 知道privateKey的人将能够解密加密的JWT .
将privateKey隐藏在服务器的安全位置，永远不要告诉任何人privateKey .
JWT中的数据经过签名和加密，并不意味着它是安全的 . JWT不为敏感数据提供保证 .
使用私钥（即发送方和接收方都知道的私钥）对数据进行加密，入侵者可以制作密钥并且可以改变内容 .
据我所知，JWT不提供安全性 .
谢谢