【问题标题】:Arguments against creating JWT on client side反对在客户端创建 JWT 的论点
【发布时间】:2021-11-30 05:49:39
【问题描述】:

一家合作伙伴公司正在创建一个我们想要使用的 RESTful 端点。

相反,他们希望使用 JWT 签名密钥提供一些适当的身份验证方式,以便我们可以创建 JWT 客户端并将 JWT 作为 JSON 主体发送到 API 端点。然后他们可以检查签名是否有效,因为他们还拥有签名密钥。

虽然这实际上似乎完成了工作,但感觉就像在滥用 JWT。

这是 JWT 的有效工作流程吗? 如果不是,反对它的论据是什么? 我想不出任何反对它的有效论据(除了感觉不对)。

【问题讨论】:

    标签: json rest jwt express-jwt


    【解决方案1】:

    我看到这个工作流的最大问题是服务器必须信任客户端包含在 JWT 有效负载中的信息。此外,如果服务器向所有用户发送相同的签名密钥,服务器将很难确认用户是否是他们所说的那个人。现在,如果服务器向每个用户发送不同的签名密钥,服务器能做的最好的事情就是将记录存储在数据库中以控制签名密钥的过期,但这使得 JWT 不再是无状态的(因为它们依赖于“状态”存储在服务器中),并且此功能的advantages 丢失。

    【讨论】:

      【解决方案2】:

      到目前为止,最好的方法是

      • 使用非对称加密
      • 生成私钥/公钥对
      • 向对方发送公钥
      • 使用我们的私钥生成 JWT。

      每当有超过 1 个参与方参与 JWT,并且他们单独生成/验证令牌并且使用非对称加密/签名时,您应该会觉得这是一个危险信号。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2021-06-21
        • 2012-04-22
        • 2017-10-02
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-06-16
        相关资源
        最近更新 更多