在 Auth0 中，jwt token 签名有 2 种算法:RS256 和 HS256。
在他们的文档中，他们描述了 RS256 的优点。有人可以向我解释使用 HS256 算法的优点吗，我现在看不到它们，但我很确定有一些。
最佳答案
您已经要求 HS256 优于 RS256，例如。
到 Oauth2/OIDC(与感知便利相关)
让我们快速浏览一下:
感知到的便利性/了解该怎么做 - 确实，将 clientId 和 clientSecret 复制到应用程序的配置中既容易理解又可以快速完成。然而，今天的库使 RS256 设置也变得简单 - 库/框架通常会提供检索公钥的功能，并使用与 HS256 类似的配置进行验证，但无需提供 secret 。如果不熟悉，请使用您选择的技术查看一些 Auth0 示例，以了解这一点。
性能 - 是的，在这里 HS256 可能有一个利基。除了缓存公共(public)证书等(对于使用 node.js 的缓存示例，请参阅 here 和 here )，拥有对称 key 并在应用程序本地使用它而根本不需要任何网络请求等，可能会证明更有效。也就是说，大多数优秀的 JWKS 库/sdks 都会处理开箱即用的缓存选项。
但实际上您应该问的问题是这些好处(性能优化？)是否超过了缺点——当然是从安全的角度来看。
如果仍然不相信，请参阅此 answer 并随时在那里发表评论(Auth0 社区网站)。对于新客户端，Auth0 已默认切换为使用 RS256，其资源 API 也默认为 RS256。
RS256 的一个主要优点胜过选择 HS256 的大多数争论，它只是不需要与客户端应用程序存储(共同定位) secret - 私钥只有授权服务器(Auth0 等)知道，并且 secret 不能泄露。仅此一点就可以告诉您为什么 RS256 在大多数情况下绝对是更好的选择。
secret 与公共(public)客户端 - 如果您的客户端被视为 Confidential Client ，您甚至应该只考虑 HS256。由于 secret 客户端能够保存 secret ，您可以选择以两种方式之一向他们颁发已签名的 ID token - 对于非 secret 客户端，您永远不应该使用 HS256，因为根据定义，客户端不能保守 secret 。
还有其他一些考虑因素也使 HS256 成为一个较差的选择，例如，如果存在签名 key 翻转，则需要使用给定的客户端配置手动更新所有应用程序。
关于jwt 签名 : RS256 or HS256，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/45878384/