了解JWT的RSA签名 [英] Understanding RSA signing for JWT

问题描述

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

I'm implementing a sign in system with the help of the JWT (JSON Web Token) scheme. Basically, after a user sign in / login, the server signs a JWT and passes it to the client.

然后，客户端随每个请求返回令牌，服务器在返回响应之前验证令牌.

The client then returns the token with each request and the server verifies the token before sending back a response.

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

This is pretty much how you would expect it, but I'm having some problems with the logic of the process. From all the mathematical articles I've read, it seems that RSA signing uses asymmetric keys for signing. As the public key, as its name suggests, is exposed to the client and the private key is kept on the server, it makes sense to sign the JWT with the public key which is sent to the client and verify it on the server side using the private key.

但是，在每个示例和库中，我看到的似乎都是相反的情况.是否知道为什么会这样吗?如果一个JWT是用私钥签名的，而又用公共密钥验证的，那又有什么意义呢?

However, on every example and library I see it seems to be the other way around. Any idea as to why it is so? If a JWT is signed with the private key and verified with the public one than whats the point?

推荐答案

首先，很抱歉，这个答案相当长.

First off, apologies, this answer got rather long.

如果您使用RSA签名令牌，并且连接的客户端是Web浏览器，则该客户端将永远不会看到RSA密钥(公共或私有).这是因为客户端大概不需要验证JWT是否有效，仅服务器需要这样做.客户端仅保留JWT，并在被询问时将其显示给服务器.然后，服务器会在看到令牌时进行检查以确保其有效.

If you use RSA to sign your tokens, and a connecting client is a web browser, the client will never see the RSA keys (public or private). This is because the client presumably doesn't need to verify that the JWT is valid, only the server needs to do that. The client just holds onto the JWT and shows it to the server when asked. Then the server checks to make sure its valid when it see's the token.

那么，为什么您需要JWT的公钥/私钥组合?首先，您不需要使用公钥/私钥算法.

So why might you need a public / private key combo for JWT's? Well first off, you don't need to use a public / private key algorithm.

您可以使用多种不同的算法对JWT进行签名，其中RSA是其中一种.签署JWT的其他常见选择是ECDSA或HMAC算法(JWT标准还支持其他).具体来说，HMAC不是公钥/私钥方案.只有一个密钥，密钥，用于对令牌进行签名和验证.您可以将其视为使用私钥来签名和验证JWT.我无论如何都不是专家，但这是我最近进行自己的研究得出的结论:

You can sign JWT's with a number of different algorithms, RSA being one of them. Other popular choices for signing your JWT's are ECDSA or HMAC algorithms (the JWT standard supports others as well). HMAC, specifically, is not a public / private key scheme. There's just one key, the key, which is used to both sign and validate the tokens. You can think of this as using the private key for both signing and validating the JWT's. I'm not an expert on this by any means, but here's the conclusions I came to from doing my own research recently:

使用HMAC很好，因为它是最快的选择.但是，为了验证JWT，您需要给某人一个可以执行所有操作的密钥，与其他人共享此密钥意味着该人现在也可以签名令牌，并假装自己就是您.如果您正在构建都需要能够验证JWT的多个服务器应用程序，则可能不希望每个应用程序都具有对令牌进行签名的能力(不同的程序员可能会维护不同的应用程序，并与更多人共享签名能力.人员存在安全隐患等).在这种情况下，最好拥有一个受到严格控制的私钥(和一个进行签名的应用)，然后与其他人共享公钥，以使他们能够验证令牌.在此，私钥用于对令牌进行签名，公钥用于对令牌进行验证.在这种情况下，您需要选择RSA或ECDSA.

Using HMAC is nice because it's the fastest option. However, in order to validate the JWT's, you need to give someone the one key that does everything, Sharing this key with someone else means that that person could now also sign tokens and pretend like they're you. If you're building multiple server applications that all need to be able to validate your JWT's, you might not want every application to have the ability to sign tokens as well (different programmers might be maintaining the different applications, sharing the signing ability with more people is a security risk, etc). In this case, it's better to have one, tightly controlled private key (and one app that does the signing) and then share the public key around with other people to give them the ability to validate the tokens. Here, the private key is used for signing the tokens, and the public key is used for validating them. In this case you'd want to choose RSA or ECDSA.

例如，您可能拥有一个全部连接到的应用程序生态系统 相同的数据库.要登录用户，每个应用都会将好友发送给一个人， 专用的登录"应用.这个程序有私钥.另一个 应用可以验证此人是否使用公共密钥登录(但 他们无法登录).

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

我所做的研究表明，在这种情况下，RSA是大多数JWT应用程序的更好选择.这是因为从理论上讲，您的应用将经常验证令牌.在验证方面，RSA比ECDSA快得多. ECDSA主要不错，因为密钥较小.这使它更适合HTTPS证书，因为您需要将公钥发送到客户端的浏览器.但是，在JWT方案中，密钥保留在服务器上，因此存储大小为n/a，验证速度更为重要.

The research I've done points to RSA being the better option for most JWT apps in this scenario. This is because your app will be, theoretically, validating tokens frequently. RSA is much faster then ECDSA at verification. ECDSA is primarily nice because the keys are smaller in size. This makes it better for HTTPS certificates because you need to send the public key to the client's browser. In the JWT scenario though, the keys are staying on a server so the storage size is n/a and the verification speed is more important.

结论:如果您要构建一个没有多个较小的微服务应用程序"的小型应用程序/您是唯一的开发人员，则可能选择HMAC来加密您的密钥.否则，可能选择RSA.再说一次，我不是专家，只是最近用谷歌搜索了这个话题的人，所以请带上一点盐.

Conclusion: if you're building a small app without multiple smaller 'micro-service apps' / you're the only developer, probably choose HMAC to encrypt your keys. Otherwise, probably choose RSA. Again though, I'm not an expert, just someone who recently googled this topic, so take this with a grain of salt.

这篇关于了解JWT的RSA签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！