JWT（JSON Web Token）是否应该加密？

Question

我正在阅读关于JWT Web令牌作为发送给用户的访问令牌的文章。其中一些提到Web令牌应该能够被用户解码。

这是否意味着解密整个Web令牌是不好的做法？例如，假设我返回以下JWT Web令牌，其中包含可以解码的信息。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

然而，我觉得我不想让用户能够解码他/她的访问令牌，所以我使用另一种加密算法将所有内容加密成另一种形式，并传回给用户。

因此，当我在服务器上获取访问令牌时，我会解密这个新的文本并进行解码。

如果我不希望向用户公开某些可用的声明值（例如用户ID），这种做法是否被推荐？如果不是，有什么替代方案？

- vincentsty

---

如果没有加密（只是签名），那么它不会成为安全漏洞吗？有足够多的这样的令牌，试错过程中最终不会破坏哈希吗？ - AlikElzin-kilaka

Vincent，你正在阅读哪篇文章？ - AlikElzin-kilaka

Answer 1

JWT（RFC7519）是一种安全传输发行者声明到受众方HTTP的简洁方式。

JWT可以：

• 签名（JWS-RFC7515）
• 加密（JWE-RFC7516）
• 先签名再加密（强烈建议按此顺序进行）。整个JWS是JWE的负载
• 先加密再签名。

如果您想从持有人（客户端）或第三方隐藏敏感信息，那么将JWS加密是有意义的。

真正的问题是：受众是否支持JWE？如果支持，支持哪些算法？

- Spomky-Labs

---

第三个要点是不正确的：建议先签名再加密，但也可以先加密再签名。请参见https://tools.ietf.org/html/rfc7519#section-11.2 - Steven Liekens

没错：即使不建议这样做，但也没有禁止这个命令。我已相应更新了答案。 - Spomky-Labs

Answer 2

JWT是“签名”的，因此其内容受到防篡改的保护：您不能更改其内容而不使它们失效。

您可以选择“加密”内容，从而仅将其展示给发行者（创建令牌的实体）和使用验证后内容的消费者（实体）。

有一个标准: JWE

- Eugenio Pace

---

简单来说，将整个JWT加密以使消费者完全不知道内容是错误的吗？我所指的是使用自己的算法再次加密整个JWT令牌，而不是选择性地加密内容。 - vincentsty

这并不是错的。它可能并不总是必要的。通常，如果信息很敏感，就需要使用它。但并不总是如此。我会坚持遵循标准。 - Eugenio Pace

我认为这里需要明确说明一点，以便其他访问者阅读时清楚，即JWT通过其签名受到篡改的保护，但是任何获得该令牌的人仍然可以看到有效载荷。如果有效载荷中包含敏感数据，则加密它可能是一个好主意。挑战在于您需要确保接收该令牌的系统能够解密该令牌，以便读取有效载荷（例如声明）。 - Sinaesthetic

为什么你会在JWT中存储敏感数据？这会让我作为用户感到担忧。 - undefined

Answer 3

令牌包含用户数据并充当临时存储。不宜将敏感数据存储在令牌中。

在第一层级别上，您应该存储用户名和可能的角色或类似信息。您不应包括密码，因此无需加密。 但是，如果您想要，您可以对其进行加密。

- A Programmer

Answer 4

JSON Web Token最佳实践，RFC 8725强调了如何从零开始正确构建JWT实现，但是目前没有来自IEEE、W3C或IETF等权威机构的建议，关于是否应该对JWT负载进行加密。

注意：如果您遵循Google和Bing的网络建议，那么您正在通过安全传输（例如HTTPS）进行响应。

关于将类似访问令牌这样的有状态信息与无状态HTTP协议绑定，可以参考cookie：限制对cookie的访问。

只要您正确实施了JWT，您签名的JWT应被视为坚不可摧，也就是说，从物理上来说几乎不可能伪造返回给服务器的有效载荷。

- Ronnie Royston

Answer 5

是的，最佳实践是使用JSON Web Encryption（JWE）RFC，解码后JWT中的声明以明文形式呈现，因此如果用户丢失令牌，则敏感信息如电子邮件、用户名、访问权限可能会被看到，并可用作任何攻击的初始信息。

- Rafael Gutiérrez

---

哪里说JWE是最佳实践，或者说JWE是推荐的？ - Ronnie Royston