security - 没有 JWT secret 的第 3 方 JWT 验证验证

Question

我想这与其说是第 3 方，不如说是受信任的第二方。在我们的应用程序中，我们有一个私有(private)的可信身份提供者，它在向该提供者成功验证后发出 JWT。我们被允许通过服务器到服务器的通信来执行此身份验证，因此它不是 3 条腿的 OAuth 流程或类似的流程。

现在 token 是一个 JWT，我们知道它什么时候过期，但这是理所当然的，所以我们不拥有用于签署 JWT 的 secret ，所以我们无法在我们这一端验证它。这是我们必须知道用户是否登录的唯一信息。这就提出了一个问题:

由于我们无法验证 token 的签名，我们只能信任一些数据，基本上任何具有一定技能的人都可以绕过身份验证流程自行设置。现在，在每个人大喊大叫之前，任何类型的用户数据呈现或任何可以更改用户数据的操作等必须都交给那个确实验证 token 的可信第二方签名，因为它拥有 secret 。

我在这里看到的主要缺陷是，假设设置了 cookie，我们只是假设“某人”已登录。实际上，他们会在菜单中看到一个“注销”按钮。第二个他们进入应用程序的任何敏感或可操作部分，虽然 token 被发送到受信任的第二方(通过 SSL)以检索或更改信息。因此，恶意创建的 token 会在那里失败。

这个想法

well they would only see a logout button at most

不适合我，因为即使 JWT 可能无法验证，应用程序已经有效地表示“此用户已登录”，并且它依赖于主应用程序当前不执行第二方之外的任何操作这一事实允许。

我很好奇是否有任何消息灵通的技术可以处理以下问题:

implicitly trust the cookie value until the 2nd party, upon an action request, says otherwise.

以下是我们想到的一些解决方案:

• 将 JWT 发送到身份提供者的每个请求以验证它

  • 感觉这从一开始就违背了 JWT 的目的。
  • 为每个请求添加一些额外的 HTTP 开销

• 第一次看到 JWT 时，我们会与第 2 方验证它，如果有效，我们自己签名

  • 由于我们会控制验证请求，因此我们知道结果是可信的。然后生成我们自己的签名将防止总是要求第 2 方进行验证。
  • 如果我们的应用需要访问某些 JWT 负载信息，我们只需确保我们的签名首先得到验证。
  • 如果我们的应用程序的增长超出了第 2 方允许的范围，这可能会增加一些 future 的证明，因为将有一种机制来拒绝恶意创建的 JWT。

显然第二种想法似乎更有利:

• 我们是否遗漏了明显的陷阱？
• 是否有更好的方法来解决这个问题？
• 这甚至是一个应该解决的问题吗？

Answer 1

您已经提到了一些明显的陷阱。

---

主要问题是他们不会向您发布共享 secret 。受信任的第 2 方应向其所有直接用户发布辅助共享 secret ，这将允许您在您的门户上验证签名，而无需联系他们的服务器来验证 JWT。

我们计划使用您将包含在您的网络门户中的 JavaScript 文件，该文件将允许您的用户直接使用我们的服务器登录。 JWT 将使用我们为您提供的共享 key 进行签名。从这里，JWT 将被发布给用户，用户将在后续请求中将其提交到您的服务器，您可以使用相同的共享 key 对其进行验证。

解决此问题将解决您提到的所有其他问题，以及 session 持久性/过期、签名撤销和使用过多 header /请求的问题。