Javascript 例如，在使用JWT时，如何保持共享秘密？

有一件很基本的事我不明白。为了使JWT安全，客户端和服务器必须共享一个秘密

但是，客户机通常是一个JavaScript应用程序，在某个完全未知的远程客户机上的浏览器中运行

---

假设我是服务器和客户端代码的作者，我如何确保客户端共享机密的安全？

您假设机密是共享的。不一定是这样。（而且它只能在相互信任的系统之间共享。您通常不能信任执行JavaScript的客户端。）

JWT的一个典型用途是，服务器使用机密生成签名数据，并将签名数据（无机密）发送到某个地方（例如，客户端），而不保留该数据。当它取回数据时，它可以验证（使用秘密而不是数据的持久副本）数据自签名后没有被篡改

那个使用模式有什么应用程序？例如，您可以通过这种方式实现基于令牌的权限，从而无需标识即可进行身份验证：

---

假设您提供了云存储服务。用户可以上传一个文件，您可以为其分配一些标识符，比如说

5

。生成一个可共享的URL，该URL将JWT签名数据“may access file#5”作为其参数之一，并向用户显示该URL。用户和他们共享此链接的每个人都可以通过该URL访问该文件。您只需验证签名是否是您创建的有效签名，以及签名数据是否指示正确的文件。当然，如果与用户共享URL的人进一步分发URL，其他人也可能通过这种方式获得访问权限。但如果不知道URL，则无法访问该文件。

这与在auth上向客户端发送cookie，然后依靠它执行其他操作相同

是的，你不能保证客户饼干的安全，它们可能会被盗。与jwt相同，令牌可能被盗

---

jwt的优点在于，令牌本身并不是cookie的一部分，因此即使在

http

通信中，您也可以使用它-即使有人获得了用户请求的有效负载或标头，他也无法使用其他数据创建新的请求，如果使用cookies，这是可能的。

您是在谈论用于构建JWT的密钥吗？因为它没有发送给客户…这可能是我最喜欢的文章之一（带picto），我不明白。它不是作为cookie的通信的一部分，而是作为授权标头中的承载令牌的通信的一部分。最终的结果是相同的——服务器“保留”来自同一用户的HTTP请求的某些状态。它和饼干有什么不同？我肯定遗漏了什么。当然，当用户收到jwt令牌时，它是通信的一部分。但在用户向服务器发送有效负载和签名之后，并不像cookie那样发送令牌本身。但为了验证签名，服务器需要相应JWT的头和有效负载部分。由于它们不是通过线路到达的，服务器需要存储它们并从数据库中获取它们。如果是这样，那就是会话管理。我认为JWT可以消除会话管理的需要。同样，我肯定遗漏了什么。您可以使用jwt进行会话管理或其他任何操作。您甚至可以编写用jwt编码的json电子邮件。或者公开发表。JWT只是关于如何在双方之间发送加密信息的标准。任何第三方，获得流-将无法解码它没有秘密密钥，这不是通信的一部分。jwt并不是什么新鲜事，它只是一个描述信息应该如何打包（json）、属性和算法应该放在哪里（header）的标准，仅此而已。JWT甚至不包含任何加密算法，因此，JWT是让服务器“保留”来自同一用户的HTTP请求的某些有限状态。只有服务器知道这个秘密。是吗？是的，尽管它不限于HTTP请求。您可以通过对包含用户ID和电子邮件地址的对象进行签名、将结果打包到URL并将该URL发送到电子邮件地址来实现电子邮件地址验证。当这样一个URL被调用并且签名是有效的（根据你的秘密），那么你就知道电子邮件已经到达并且确认链接已经被点击。“秘密保留在发送者和接收者身上”-教程视频（2:05）。所以我仍然不明白如何保守发送者（Javascript）部分的秘密。好吧，@Osi，在我勾勒出的用例中，“发送者”和“接收者”都是web服务器，JS客户端只是充当一个代理，可以决定是否、何时（以及多久）转发消息。当然，JWT也可以实现很多其他场景。