场景:网络应用程序用户想要创建私有(private) Assets 的授权 View 。用户已通过身份验证并拥有 jwt token 。该应用程序想要创建一个新的辅助 jwt token ，可以验证该 token 是使用原始 token 创建的。
仅供引用:我的用例是签署一个 url - 将第二个 jwt token 添加到该 url，以允许受控的公共(public)查看私有(private) Assets 。
应用程序应该如何做到这一点？
例如是否有推荐的方法来为第二个 token 设置 secret 和 alg ？
最佳答案
理论上，要使用一个 jwt 来签署另一个 jwt，您可以使用 HS256 算法，并以第一个 jwt 作为 secret 。实际上，这种方法会导致一些问题，概述如下:
首先，只有服务器和原始 token 持有者才能验证该 token 的真实性，并且为了让服务器执行验证，您需要将原始 token 保留在某处。这超出了您的问题的范围，但它确实开始使实现变得复杂，因为现在两个 token 必须共享一个生命周期，并且无论何时使用第二个 token ，原始 token 都需要可用。对于您的用例来说，这可能不是问题，但它确实在一定程度上限制了可移植性，以及 future 的证明，例如，如果另一方需要验证 token (通过使用 RS256 可以在没有太多开销的情况下实现此类用例)和非对称 key 而不是 HS256/对称 key 方法)。
其次，JWT 通常是生命周期较短的 transient 值。这通常是由于它们的使用性质所致:由于它们在客户端和服务器之间共享，因此严格来说它们并不是“ secret ”值，并且它们存在的时间越长，受到损害的可能性就越大。在将它们用作其他代币的 secret Material 时，您现在需要这些代币更长的生命周期，并且您可能会引入一个安全漏洞，其中“辅助”代币可能会被获得这些“主要”代币之一的攻击者欺骗。 ” token 。为了减轻这种特定威胁， secret Material 应该不通过网络传输。
也许您可能会考虑对两个 token 使用相同的 token 生成过程(相同的算法和 secret )，并且只需包含“发行者”的标识符(持有原始 token 的用户的唯一标识符)作为第二个 token 。使用此方法，您无需担心给定 token 使用哪个验证过程(因为现在两者相同)，也不必担心 token 生命周期或通过被盗 token 进行 key 欺骗。
关于javascript - 如何使用一个 JWT token 签署第二个 JWT token ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/66462406/