为什么我应该让JSON Web Token负载不加密？

Question

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

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

1）我总是看到运送JWTs并从服务器不一致的手段。 For example, here：用于检索标记的一种传输方法（通过POST主体中的JSON编码对象），另一种用于提交它的方法（通过HTTP标头）。为什么这种不一致？当然，这取决于实施者选择方法，但至少要保持一致并且只使用标题或仅使用正文，这不是好的做法吗？

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

Answer 1

1）我一直看到不一致的方式将JWT传输到服务器和从服务器传输。至少要保持一致并且只使用标题或仅使用正文，这不是一种好的做法吗？

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

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

JWT保留后端状态，而不是客户端状态。后端状态可能是User 128 is logged in as administrator。这是（在我的例子中）存储在智威汤逊的Subject和Scopes。客户端不会发送包含此信息的后端会话的ID，而是直接在JWT中提供信息。后端因此不必保持存储用户128的logged in state的会话。如果客户端请求信息User 2，则BE可以判定如果JWT告知登录的用户具有ID 1，则该信息被禁止。

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

该状态通常对客户不是秘密。客户端不能相信JWT中的信息，因为它无法访问用于验证JWT的密钥，但它仍然可以根据JWT中的信息调整GUI等。 （就像显示管理GUI的按钮一样。）

为什么要将应用程序数据的两种获取方式混合到客户端并同时使用JWT有效内容和正常的数据回复体？

参见上文，JWT的主要目的是将信息保留在后端而非客户端。一旦用户登录，后端询问：“嘿，你能为我保存这个信息并将它附加到每个请求中，以便我可以在此期间忘记你吗？”就像你的经理要求你在你的裙子上戴上名字贴纸，这样他/她不必记住你的名字。 :-)（他/她签署它，这样你不能改变它没有他/她注意到。

应该不是最好的做法是保持JWT始终处于加密状态？它只能在服务器端进行更新

它并没有真正带来任何安全性，除非你在JWT中存储秘密信息，并且该托架更适合做服务器端解密与仅仅验证签名相比更加麻烦。

[1] Local Storage vs Cookies