在RESTful API的上下文中，使用RSA签署JWT比SHA有什么优势？

我有一个后端，它公开了一个RESTful API，该API目前是“免费的”（但使用https）

现在我想添加RBAC（基于角色的访问控制）和JWT，这似乎是一个不错的选择，我读了很多关于JWT的书，但是没有看到使用RSA而不是SHA来签署令牌的优势

假设用户已经认证并获得了一个密钥，无论是共享的还是公共/私有的

现在，在我看来，在这两种情况下（SHA或RSA HMAC），双方（客户机和服务器）都必须拥有共享密钥，或者在RSA的情况下，拥有其私钥/公钥的一半。服务器必须根据JWT中的声明找到该密钥（在表或数据库中），以便验证令牌的签名。一旦确认JWT中的声称用户，它将使用配置的角色授权请求

---

那么，在这种情况下，RSA的优势是什么呢？

我假设您在这里谈论的是RSxxx（例如RSA256）和HSxxx（例如HS256（HMAC-SHA256））算法。主要区别在于HS256是对称算法，而RS256是非对称算法。对称算法仅使用一个密钥（或秘密）进行签名和验证，而非对称算法使用私钥进行签名，使用公钥验证令牌

如果您共享用于HS256的秘密，每个知道该秘密的人都可以发布、修改和重新签署令牌。如果你与客户分享秘密，那将破坏签名的目的。在RS256或任何其他非对称算法的情况下，只有身份验证服务器知道私钥，需要验证令牌的任何人都可以使用公钥进行验证。匹配密钥通常由令牌头中的

KID

（密钥Id）声明标识

---

但通常，签名和验证只在服务器端完成，客户端不需要验证令牌，因此根本不需要知道密钥或秘密。因此，您可以在简单服务的情况下，当身份验证和资源服务器相同时，仍然依赖于对称算法。但是，一旦您为多个资源服务器提供了一个单独的身份验证服务器，就应该使用非对称算法。

感谢您的响应，这确实有助于让它更清晰

所以基本上，对于一个简单的RESTful API，使用RSA与HSA相比没有真正的优势

---

关于基于令牌的身份验证，一些要点可能会帮助其他人：

序言：以下内容都是在使用SSL的上下文中介绍的

首先，令牌是用户名/密码凭据的替代品：如果客户机有令牌，则等同于拥有用户名/密码。我花了一段时间才弄明白。有点像在公司的打印机上使用徽章：不用输入用户名和密码，只需将徽章（令牌）放在打印机上，它就会知道你是谁并打印你的文档

然而，令牌使使用API变得更简单，因为

• 客户端只需将其令牌添加到http头中
• 服务器只验证令牌
• 两者都不必处理涉及用户名/密码和管理会话cookie的身份验证流

但缺点是

• 丢失令牌就像丢失用户名/密码一样，并且
• 在涉及许多组件的复杂系统中，令牌必须在所有涉及的后端服务器之间共享

其次，客户不需要严格验证代币——它只需要代币——如果有人给你一把他们房子或汽车的钥匙，你通常不会检查钥匙，你信任这个人（有时可能很愚蠢）并使用它。因此，一个简单的随机字符串可以用作令牌；服务器维护一个简单的表，将令牌与用户关联起来，根本不涉及密钥。如果客户端发送的令牌表明服务器没有-->访问被拒绝。如果有匹配的令牌-->请查找与该令牌相关的用户（通常后跟授权）

第三，服务器通常基于对客户机的信任，或者在客户机以某种方式进行身份验证之后（例如）生成令牌。非统组织。之后，客户机只是在每个请求中发送令牌，服务器在其表中查找令牌。然而，这种用于随机字符串令牌的服务器端表可能会变大，并且必须是持久的，因此需要数据库或文件，它们通常比较慢，需要维护等，因此使用加密签名和jwt输入：

第四，签名代币：

• 服务器对令牌进行签名并将其发送到客户端-但服务器不必存储令牌，也不必存储如上所述的会话cookie
• 客户端安全地存储令牌，并在每次后续请求中发送它（就像随机字符串令牌一样）
• 服务器接收请求，计算jwt的签名，并将其与客户端发送的令牌的签名进行比较。请注意，没有文件或数据库查找，只是再次计算签名并将其与客户端发送的签名进行比较。如果签名匹配，则令牌必须与服务器发出的令牌相同，因此jwt头和负载也与服务器发出的令牌相同
• 服务器现在解释有效负载，特别是用户（通常执行授权）

因此，使用jwt意味着服务器不需要

• 具有用户名和令牌的数据库或文件
• 保存代币
• 维护会话cookie的步骤

它只需要创建和比较签名。为此，它需要一个加密密钥。这可以是简单API的对称密钥，也可以是必须共享公钥的更复杂系统的非对称密钥

---

希望这能帮助其他受苦受难的人解决这个问题。

…但服务器保存的原因可能还有其他原因