为什么我应该不加密 JSON Web 令牌有效负载？答案

【问题标题】：Why should I leave JSON Web Token payload nonencrypted?为什么我应该不加密 JSON Web 令牌有效负载？
【发布时间】：2017-07-10 08:57:20
【问题描述】：

我正在阅读 JWT，有太多的教程和太多的方法，令人困惑。

我有几个关于正确使用 JWT 的问题：

1) 我一直看到在服务器之间传输 JWT 的方式不一致。 For example, here：一种用于检索令牌的传输方法（通过 POST 正文中的 JSON 编码对象），另一种用于提交它的方法（通过 HTTP 标头）。为什么会有这种不一致？当然，由实现者来选择方法，但至少保持一致并仅使用标头或仅使用正文不是一个好习惯吗？

2) JWT 有效负载包含状态信息，因为服务器没有维护它。很明显，应该将有效负载的大小保持尽可能小，因为 JWT 的大小会添加到每个请求和响应中。也许只是一个用户 ID 和缓存的权限。当客户端需要任何信息时，它可以通过（通常是 JSON 编码的）HTTP 正文接收它并将其存储在本地存储中，似乎不需要出于相同目的访问只读 JWT 有效负载。那么，为什么要保持 JWT 有效负载不加密呢？为什么混合使用两种获取应用程序数据到客户端的方式并同时使用 JWT 有效负载和正常的 data-in-response-body ？最佳实践不应该是保持 JWT 始终加密吗？无论如何只能在服务器端更新。

【问题讨论】：

标签： json jwt

【解决方案1】：

1) 我一直看到在服务器之间传输 JWT 的方式不一致。 [...] 至少保持一致并仅使用标题或仅使用正文不是一个好习惯吗？

这可能取决于客户。虽然 Web 应用程序可以通过将 JWT 存储在 cookie 存储中来获得更高程度的安全性，但本机应用程序可能更喜欢本地存储来访问 JWT 信息。 [1]

2) JWT 负载包含状态信息，因为服务器没有维护它。很明显，应该将有效负载的大小保持尽可能小，因为 JWT 的大小会添加到每个请求和响应中。也许只是一个用户 ID 和缓存的权限。当客户端需要任何信息时，它可以通过（通常是 JSON 编码的）HTTP 正文接收它并将其存储在本地存储中，似乎无需出于相同目的访问只读 JWT 有效负载。

JWT 保持后端状态，而不是客户端状态。后端状态可能是User 128 is logged in as administrator。这（在我的示例中）存储在 JWT 中的 Subject 和 Scopes 字段中。与客户端发送包含此信息的后端会话的 ID 不同，该信息直接在 JWT 中。因此，后端不必保留存储用户 128 的logged in state 的会话。如果客户端请求User 2 的信息，如果 JWT 告诉登录用户有 ID，则 BE 可能决定禁止该信息1.

那么，为什么要保持 JWT 有效负载不加密？

状态通常不会对客户端保密。客户端无法信任 JWT 中的信息，因为它无法访问用于验证 JWT 的密钥，但它仍然可以根据 JWT 中的信息调整 GUI 等。（比如是否显示管理 GUI 的按钮。）

为什么混合使用两种获取应用程序数据到客户端的方式并同时使用 JWT 有效负载和普通 data-in-response-body？

见上文，JWT 的主要目的是将信息保存在后端，而不是客户端。用户登录后，后端会询问“嘿，您能帮我保留此信息并将其附加到每个请求中，以便我在此期间忘记您吗？”就像你的经理要求你在裙子上贴一个名字贴纸，这样他/她就不必记住你的名字。 :-) （并且他/她在上面签名，这样你就不能在他/她不注意的情况下更改它。

最好的做法不应该是让 JWT 始终加密吗？无论如何只能在服务器端更新。

除非您将机密信息存储在 JWT 中，否则它并不会真正带来任何安全性，并且最好在服务器端进行存储。解密比只验证签名要麻烦一些。

[1]Local Storage vs Cookies

【讨论】：