服务器如何验证 JWT？公钥从哪里来？答案

【问题标题】：How does a server verify a JWT? Where does the Public Key come from?服务器如何验证 JWT？公钥从哪里来？
【发布时间】：2020-11-16 06:32:59
【问题描述】：

我正在查看 Node.js 中 JWT 令牌的 examples 和 verify 函数。我的问题是，这个publicKey 来自verify(token, publicKey) 的哪里？什么是流量？

客户端（我的一个用户）在他们的计算机/服务器上安装了一个客户端库，用于向我的应用程序myapp.com 发出请求。在myapp.com 服务器中，我调用verify(token, publicKey)。在客户端库中，我使用privateKey 生成令牌。问题是，客户端一般是如何获取这个私钥的？（即heroku login 是在后台下载私钥以发出 JWT 请求吗？）。您如何获取公钥？我的理解是，客户端会下载一个私钥，而我们的服务器会存储公钥。然后如果你有公钥和令牌，只需调用verify(token, publicKey)。但是一般如何在服务器上获取令牌的公钥呢？服务器是否为每个私钥存储一个公钥并分发给客户端安装的库？

【问题讨论】：

标签： security jwt public-key-encryption

【解决方案1】：

按照我通常看到的 JWT 使用方式，只有极少数受信任的发行者，通常只有一个，并且令牌用作不记名令牌。在许多情况下，发行者和验证者是相同的。在其他情况下，验证者信任一个身份提供者（例如 Google）并从 https URL (example) 获取公钥。

在您的情况下，您可以同时充当发行者和验证者：

您（服务器）将生成一个密钥对。
您的 API 服务器会信任由该密钥签名的 JWT（并且它们只有公钥，因为它们只需要验证它们）。
身份验证/管理服务器将拥有 private 密钥，对您的用户进行身份验证，并向他们颁发 JWT。
客户端永远不会处理任何密钥，他们只会存储签名的 JWT，并在发出客户端请求时将其作为不记名令牌传递。

这是例如该方法将 here 描述为 GitHub 使用的方法。在这种情况下，发行者和验证者都属于您。这种方法对您（验证签名后您可以信任 JWT 的内容）和客户端（它们只是处理不透明的 API 密钥，不需要处理复杂性）都是最简单的JWTs)。

一种可能的替代方法是：

生成密钥对，公钥与帐户相关联。这可以通过多种方式完成（见下文），但最终结果是相同的：客户端有一个私钥，您的服务器知道相应的公钥以及它与哪个用户关联
在发出请求时，客户端会创建一个 JWT，使用其私钥对其进行签名，并在令牌中包含他们的用户名（例如，在iss 和或sub 字段中） .
您的服务器获取令牌，提取用户名，在数据库中查找与帐户关联的公钥，然后验证令牌。

使用这种方法，例如通过谷歌云for service account authentication。

上面的步骤 1 可以通过两种方式完成：

您对用户进行身份验证，生成密钥对，将公钥与帐户相关联，并让用户下载他们的私钥（当然是通过 https）。虽然通常认为为其他人生成密钥有点糟糕（因为您会看到一个您不需要知道的密钥并且您必须通过网络发送它），但这要容易得多，而且 Google 正在做这个。
用户生成并存储密钥对。您对用户进行身份验证，用户上传公钥，然后将其与帐户相关联。

无论如何，如果您采用“用户签署 JWT”方法，您可能需要提供客户端库，或者至少提供代码示例。另请注意 Google 要求令牌必须是短期的，通过将长期令牌视为无效来强制执行。如果没有此规则和强制执行，将会发生的事情是，许多客户端开发人员会对您复杂的解决方案感到恼火，在他的笔记本电脑上手动签署一个永久有效的令牌，然后将其用作不记名令牌。

heroku login 实际上根本不使用 JWT。它retrieves and stores 是一个 OAuth 承载令牌。这与第一种方法最相似（客户端从不处理任何私钥，只是获取一个不透明的 blob，它恰好是您可以验证的 JWT）。非 JWT 令牌和长期 JWT 之间的区别在于，您的 API 服务器必须在数据库中查找常规令牌的含义和有效性，而 JWT 直接告诉您用户身份，可能还有权限和其他您在发布时包含的属性。

【讨论】：