如果是通过Web应用程序，则是指在客户端浏览器中运行并需要向您的服务发出安全请求的JavaScript和HTML应用程序，这不是机密信息"客户".您不能将机密存储在基于浏览器的应用程序中，因为这些秘密将对所有人可见.

If by web application you mean a JavaScript and HTML app that runs in the client browser and needs to make secure requests to your service, that is not a "confidential client". You cannot store secrets in a browser based app, as they will be visible to all.

如果使用Web应用程序，是指需要向服务器发送服务器请求的服务器端应用程序，则它是机密客户端"，因为执行代码和机密无法公开审查.

If by web application you mean a server-side application that needs to make server to server requests, that is a "confidential client" because the executing code and secrets are not available to public scrutiny.

我将其他身份验证方法"解释为表示可以在一个请求中完成的，通过HTTP(或https)习惯的任何身份验证方案.使用TLS的客户端证书身份验证也可能属于此类别.我认为OAuth2 4.4客户端凭据授予的主要部分是客户端应用通过现有的身份验证方法直接向OAuth令牌服务提供凭据.该示例使用HTTP Basic身份验证，但这只是一个示例.

I interpret the "other authentication methods" to mean any authentication scheme that is customary over http (or https) that can be completed in one request. Client certificate authentication using TLS might also fall into this bucket. I think the main part of the OAuth2 4.4 Client Credentials Grant is that the client app presents credentials directly to the OAuth token service via existing authentication methods. The example uses HTTP Basic authentication, but that's just one example.

客户端凭据授予与资源​​所有者凭据授予(4.3)的主要区别在于，资源所有者授予在http请求的正文中而不是在Authorization标头中显示用户凭据.具有资源所有者授权的其他授权方法将很难使用.

Client credentials grant differs from the resource owner credentials grant (4.3) primarily in that the resource owner grant presents the user credentials in the body of the http request instead of in the Authorization header. It would be difficult to use other authorization methods with resource owner grant.

将其他身份验证方法与客户端证书授予"一起使用时，最大的警告是，OAuth2客户端库对HTTP Basic auth以外的其他任何支持的充其量都是充其量.即使您将摘要或客户端证书身份验证与客户端凭据一起使用在OAuth2规范之内，但我也怀疑现有的OAuth2客户端库是否会为您的特定排列提供内置支持.看看是否可以找到一些大型企业(例如Google或Yahoo)使用HTTP Basic auth以外的任何方法来进行客户端凭据授予的示例.在那里使用的东西更有可能由OAuth客户端库(尤其是它们附带的库！)支持.

The greatest caveat in using other authentication methods with the Client Credentials Grant is that support for anything other than HTTP Basic auth by OAuth2 client libraries will likely be spotty at best. Even if your use of digest or client cert auth with Client Credentials is within the OAuth2 spec, I'm doubtful that existing OAuth2 client libs will have built-in support for your particular permutation. See if you can find examples of client credentials grant using anything other than HTTP Basic auth by some of the big players such as Google or Yahoo. Things used there are more likely to be supported by OAuth client libs (especially the libs they ship!).

如果您拥有连接的两端，那么这并不重要.您可以做任何您想做的事情，找到一个客户端库，该库可以让您调整或调整请求以适合您的需求.

If you own both ends of the connection, this doesn't really matter. You can do whatever you want and find a client lib that will let you tweak or tailor the request to fit your needs.

如果您希望任意客户端使用客户端凭据授予来连接到您的服务，则应计划提供文档和示例代码，以说明客户端应如何显示所需的凭据.现成的OAuth2客户端库可能不会为您的方案提供自动支持.

If you want arbitrary clients to connect to your service using client credentials grant, you should plan on providing documentation and sample code of how clients should present the credentials you require. Off the shelf OAuth2 client libs probably won't provide automatic support for your scheme.