rsa - 了解 JWT 的 RSA 签名

Question

我在 JWT(JSON Web Token)方案的帮助下实现了一个登录系统。基本上，在用户登录/登录后，服务器对 JWT 进行签名并将其传递给客户端。

然后客户端在每个请求中返回 token ，服务器在发回响应之前验证 token 。

这几乎是您所期望的，但是我在流程的逻辑上遇到了一些问题。从我读过的所有数学文章中，似乎 RSA 签名使用非对称 key 进行签名。顾名思义，公钥向客户端公开，而私钥保存在服务器上，因此使用发送给客户端的公钥对 JWT 进行签名并在服务器端使用验证它是有意义的私钥。

但是，在每个示例和库中，我看到它似乎是相反的。知道为什么会这样吗？如果 JWT 使用私钥签名并使用公共(public) key 进行验证，那有什么意义呢？

Answer 1

首先，抱歉，这个答案很长。
如果您使用 RSA 对 token 进行签名，并且连接的客户端是 Web 浏览器，则客户端将永远不会看到 RSA key (公共(public)或私有(private))。这是因为客户端可能不需要验证 JWT 是否有效，只有服务器需要这样做。客户端只是持有 JWT 并在被询问时将其显示给服务器。然后服务器检查以确保它在看到 token 时有效。
那么，为什么您需要 JWT 的公钥/私钥组合呢？首先，您不需要使用公钥/私钥算法。
您可以使用多种不同的算法签署 JWT，RSA 就是其中之一。签署 JWT 的其他流行选择是 ECDSA 或 HMAC 算法(JWT 标准支持 others as well )。具体来说，HMAC 不是公钥/私钥方案。只有一个 key ，即 key ，用于对 token 进行签名和验证。您可以将其视为使用私钥对 JWT 进行签名和验证。无论如何，我都不是这方面的专家，但这是我最近通过自己的研究得出的结论:
使用 HMAC 很好，因为它是最快的选择。但是，为了验证 JWT，您需要给某人一个可以做所有事情的 key ，与其他人共享此 key 意味着该人现在也可以签署 token 并假装他们是您。如果您正在构建多个都需要能够验证您的 JWT 的服务器应用程序，您可能不希望每个应用程序也都具有签名 token 的能力(不同的程序员可能正在维护不同的应用程序，与更多人共享签名能力人是安全风险等)。在这种情况下，最好拥有一个严格控制的私钥(以及一个执行签名的应用程序)，然后与其他人共享公钥，让他们能够验证 token 。在这里，私钥用于签署 token ，而公钥用于验证它们。在这种情况下，您需要选择 RSA 或 ECDSA。

As an example, you might have an ecosystem of apps that all connect tothe same database. To log users in, each app sends folks to one,dedicated, 'logging in' app. This app has the private key. The otherapps can verify that the person is logged in using the public key (butthey can't log people in).

我所做的研究表明，在这种情况下，对于大多数 JWT 应用程序来说，RSA 是更好的选择。这是因为从理论上讲，您的应用会频繁地验证 token 。 RSA 在验证方面比 ECDSA 快得多。 ECDSA 主要是因为 key 的大小更小。这使得 HTTPS 证书更好，因为您需要将公钥发送到客户端的浏览器。但在 JWT 场景中， key 保留在服务器上，因此存储大小为 n/a，验证速度更为重要。
结论:如果您正在构建一个没有多个较小“微服务应用程序”的小型应用程序/您是唯一的开发人员，可能会选择 HMAC 来加密您的 key 。否则，可能会选择 RSA。再说一遍，我不是专家，只是最近在谷歌上搜索过这个话题的人，所以对此持保留态度。