提问者:小点点

在RESTfulAPI中,与RSA签署JWT比SHA有什么优势?


我有一个后端,它公开了一个RESTfulAPI,目前对所有人免费(但使用https)。

我现在想添加RBAC(基于角色的权限改造),JWT似乎是要走的路,我读了很多关于JWT的文章,但没有看到使用RSASHA来签署令牌的优势。

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

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

那么在这种情况下,RSA有什么优势呢?


共2个答案

匿名用户

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

如果您共享用于HS256的秘密,每个知道该秘密的人都可以发布或修改并重新签署令牌。如果您与客户端共享秘密,这将破坏签名的目的。在RS256或任何其他非对称算法的情况下,只有身份验证服务器知道私钥,任何需要验证令牌的人都可以使用公钥来验证。匹配的密钥通常由令牌标头中的KID(Key Id)声明标识。

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

匿名用户

感谢您的回复,这确实有助于使它更清晰。

所以基本上,对于一个简单的RESTfulAPI,使用RSA比HSA没有真正的优势。

关于基于令牌的身份验证的一些要点可能对其他人有所帮助:

序言:以下都是在使用SSL的背景下。

首先,令牌是用户名/密码凭证的替代品:如果客户端有令牌,它就相当于有用户名/密码。我花了一段时间才弄清楚。有点像在公司打印机上使用徽章:不是输入用户名和密码,而是将徽章(令牌)放在打印机上,它会知道你是谁并打印你的文档。

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

  • 客户端只需将其令牌添加到超文本传输协议头中,
  • 服务器只验证令牌,
  • 都不必处理涉及用户名/pw和管理会话cookie的身份验证流。

但缺点是

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

其次,客户端并不严格需要验证令牌——它只需要令牌——如果有人给你他们房子或汽车的钥匙,你通常不会检查钥匙,你信任这个人(有时可能愚蠢地这样做)并使用它。所以一个简单的随机字符串可以作为令牌;服务器维护一个简单的表,将令牌与用户关联起来,根本不涉及密钥。如果客户端发送了服务器没有的令牌-

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

第四,带签名的代币:

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

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

  • 带有用户名和令牌的数据库或文件
  • 保存令牌
  • 维护会话cookie

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

希望这能帮助其他一些饱受折磨的灵魂,他们正在努力解决这个问题。