我正在阅读JWT，有很多教程和很多方法，令人困惑。
关于正确使用JWT，我有几个问题：
1）我一直看到将JWT传送到服务器和从服务器传送JWT的方法不一致。 For example, here：一种用于检索令牌的传输方法（通过POST主体中的JSON编码对象），另一种用于提交它的方法（通过HTTP头）。为何如此不一致？当然，由实施者来决定选择方法，但至少要保持一致并且只使用标题或仅使用正文，这不是一个好习惯吗？
2）JWT有效负载包含状态信息，因为服务器没有维护它。很明显，应该保持有效载荷的大小尽可能小，因为JWT的大小被添加到每个请求和响应中。也许只是用户ID和缓存权限。当客户端需要任何信息时，它可以通过（通常是JSON编码的）HTTP主体接收它并将其存储在本地存储中，似乎不需要为同一目的访问只读JWT有效负载。那么，为什么要保持JWT有效负载不加密？为什么要将两种获取应用程序数据的方式混合到客户端并同时使用JWT有效负载和正常的数据响应体？最佳做法不应该是让JWT始终加密吗？它无论如何都只能在服务器端更新。
答案 0 :(得分：2)
1）我一直看到将JWT传送到服务器和从服务器传送JWT的方法不一致。 [...]至少要保持一致并且只使用标题或仅使用正文，这不是一个好习惯吗？
这可能取决于客户。虽然通过将JWT存储在cookie存储中，Web应用程序可以获得更高程度的安全性，但是本机应用程序可以优先使用本地存储来访问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告知记录，则BE可以决定禁止该信息。在用户中有ID 1。
那么，为什么要保持JWT有效负载不加密？
国家通常不是客户的秘密。客户端不能信任JWT中的信息，因为它无法访问用于验证JWT的密钥，但它仍然可以从JWT中的信息调整GUI等。 （比如显示管理GUI的按钮。）
为什么要将两种获取应用程序数据的方式混合到客户端并同时使用JWT有效负载和正常的数据响应体？
见上文，JWT的主要目的是将信息保留在后端，而不是客户端。一旦用户登录，后端就会问＆＃34;嘿，您能为我保留这些信息并将其附加到每个请求中，以便我在此期间可以忘记您吗？＆＃34;就像你的经理要求你在你的裙子上贴一个名字贴纸一样，这样他/她就不必记住你的名字了。 :-)（并且他/她签名以便在没有他/她注意的情况下你不能改变它。
最佳做法是保持JWT始终加密吗？它无论如何都只能在服务器端更新。
除非您在JWT中存储秘密信息，否则它并没有真正带来任何安全性，并且该服务器端更好。与仅验证签名相比，解密比解密更麻烦。