使用 RSA256(非对称)签名的 JWT 时是否需要共享机密?

Is a shared secret even necessary when using RSA256 (asymmetric) signed JWT?

人们经常读到 ResourceOwnerCredentials 流程很糟糕,因为不受信任的客户端(例如 Javascript 或移动应用程序)不能涉及密钥。

如果令牌是非对称签名的并且可以由客户端使用 OAuth 2.0 服务器提供的 public 密钥 JWK(Json Web 密钥)进行验证,这是否有效?

您误解了“资源所有者密码凭据授予”(link to spec.)

此流程的作用是,用授权代码替换资源所有者(如果是个人,则为最终用户)的凭据。正如规范所说,它可用于替换遗留系统,例如使用基本身份验证的系统。为此,应在客户和资源所有者之间建立信任。找到了一篇很好的文章,您可以在这篇文章中阅读更多内容 link

另一方面,Client Credentials Grant 是一种需要客户端获取和维护的授权(link to spec.)。而且这笔补助只适用于机密客户

The client credentials grant type MUST only be used by confidential clients.

我相信您对两种不同的资助类型感到困惑。如您所见,移动应用程序和 JavaScript 应用程序是 public 客户端。所以客户端凭证授予不能用于他们。

此外,一旦确实可以使用 public 密钥验证令牌,但要做到这一点,应该通过完成有效流程来获取令牌。

对于机密客户端,共享机密可用于加密令牌。但这不能为 public 客户端完成,因为他们无法维护共享秘密。

无论如何,这里是使用客户端身份验证的用例(如规范中所述:Client authentication

  • Enforcing the binding of refresh tokens and authorization codes to the client they were issued to. Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full.

  • Recovering from a compromised client by disabling the client or changing its credentials, thus preventing an attacker from abusing stolen refresh tokens. Changing a single set of client credentials is significantly faster than revoking an entire set of refresh tokens.

  • Implementing authentication management best practices, which require periodic credential rotation. Rotation of an entire set of refresh tokens can be challenging, while rotation of a single set of client credentials is significantly easier.

事实上,机密客户端允许您通过更改共享密钥

灵活地更改客户端身份验证