如果你能解码JWT，那么它们是如何安全的呢？

Question

如果我得到一个JWT并且我可以解码有效负载，那怎么会安全呢？难道我不能直接从报头中抓取令牌，解码并更改有效负载中的用户信息，然后用同样正确的编码秘密将其发回吗？

我知道他们必须是安全的，但我只是真的想了解技术。我错过了什么？

Answer 1

您可以转到jwt.io，粘贴令牌并阅读内容。这对很多人来说是一个不和谐的开始。

简单的回答是JWT本身并不关心加密。它关心验证。也就是说，对于“这个代币的内容有没有被操纵”，它总能得到答案？这意味着用户对JWT令牌的操作是徒劳的，因为服务器将知道并忽略该令牌。服务器在向客户端发出令牌时根据有效负载添加签名。稍后，它将验证有效负载和匹配签名。

合乎逻辑的问题是什么动机不关心自己加密的内容？

>

最简单的原因是因为它假设这是一个大部分已解决的问题。如果处理客户端（例如web浏览器），您可以将JWT令牌存储在cookie中，该cookie是secure（不通过HTTP传输，仅通过HTTPS传输）和httponly（Javascript无法读取），并通过加密通道(HTTPS)与服务器对话。一旦您知道在服务器和客户机之间有一个安全通道，您就可以安全地交换JWT或任何您想要的东西。

这让事情变得简单。一个简单的实现使采用更加容易，但它也允许每一层做它最擅长的事情（让HTTPS处理加密）。

JWT不是用来存储敏感数据的。一旦服务器接收到JWT令牌并对其进行验证，它就可以自由地在自己的数据库中查找用户ID以获得该用户的其他信息（如权限、邮政地址等）。这使JWT保持了较小的尺寸，并避免了无意中的信息泄漏，因为大家都知道不要在JWT中保留敏感数据。

这与Cookie本身的工作原理没有太大区别。Cookie通常包含未加密的有效负载。如果您使用的是HTTPS，那么一切都是好的。如果不是，那么最好对敏感cookie本身进行加密。如果不这样做，就意味着中间人攻击是可能的--代理服务器或ISP读取cookie，然后假扮成您重放它们。出于类似的原因，JWT应该始终在像HTTPS这样的安全层上进行交换。

Answer 2

JWT可以是签名的、加密的或两者兼而有之。如果一个令牌有签名，但没有加密，每个人都可以读取它的内容，但当你不知道私钥时，你就不能更改它。否则，接收方将注意到签名不再匹配。

回答你的评论：我不确定我是否正确地理解了你的评论。只是为了确定一下：您了解和理解数字签名吗？我只简单解释一个变体(HMAC，它是对称的，但还有很多其他的）。

让我们假设Alice想要向Bob发送一个JWT。他们都知道一些共同的秘密。马洛里不知道这个秘密，但想要干涉和改变JWT。为了防止这种情况，Alice计算散列（有效载荷+秘密）并将其附加为签名。

当接收到消息时，Bob还可以计算散列（有效载荷+秘密）来检查签名是否匹配。但是，如果Mallory更改了内容中的某些内容，她将无法计算匹配的签名（即hash(newContent+secret))。她不知道这个秘密，也没有办法知道。这意味着如果她更改了某些内容，签名将不再匹配，并且Bob将不再接受JWT。

让我们假设，我向另一个人发送消息{“id”：1}并用哈希（内容+秘密）签名。(+在这里只是串联）。我使用SHA256哈希函数，得到的签名是:330E7B0775561C6E95797D4DD306A150046E239986F0A1373230FDA0235BDA8C。现在轮到您了：扮演Mallory的角色，尝试对消息{“id”：2}进行签名。你不能因为你不知道我用了哪个秘密。如果我假设收件人知道秘密，他可以计算任何消息的签名并检查它是否正确。