OAuth 2.0 支持多种不同的授权类型，它们使客户端应用程序能够以不同的方式代表资源所有者与资源服务器进行交互。

使用授权存在安全隐患，implicit授权是不需要客户端密码的类型。具体来说，在这个授权流程中，客户端（因为没有客户端密码）完全依赖资源所有者（通常是使用浏览器的用户）来获取、呈现和保留访问令牌。这显着提高了保护令牌所需的标准（您真的不能让应用程序依赖这种不受 TLS/HTTPS 完全保护的授权类型），并且在没有客户端应用程序的情况下令牌被盗和滥用的额外风险知识。由于这些额外的风险，RFC 特别建议您不要依赖隐式授权，除非您必须这样做。

如果您的应用程序确实能够正确保护客户端机密，则建议改用authorization code授权类型。这允许通过应用程序管理授权流程，并消除了资源所有者在外部处理授权过程的要求，并且对客户端不透明。这意味着客户端也可以保护访问令牌，并且不需要依赖用户来保证它们的安全。

因此，客户端密码不是一个无关紧要的选项。它是首选选项的组成部分。implict对于无法实现更好选项的客户端应用程序，不需要客户端机密 的授权类型只是一种最后的手段。

我还没有阅读规范，所以我在这里做出假设，但它可以让您支持基本客户端并根据客户端是否向您发送 client_secret 来区分。例如，如果他们没有向您发送 client_secret，您可以对您发送回客户端的 request_token 强制执行更严格的到期规则。

只有当您可以信任链中的另一方来维护该信息的机密性时，OAuth client_secret 之类的私人机密才有效。所以这条规则意味着如果客户端无法保持保密，它应该通过不提供client_secret来向服务器明确。该规则的结果是，如果客户端向您发送 client_secret，则意味着它必须能够保证保密并且您可以信任它这样做。从服务器的角度来看，这意味着您知道客户端是否可以保持保密并因此相应地调整安全策略。你不必这样做，但你可以。