OAuth2不同的客户端身份验证方法 [英] OAuth2 different client authentication methods

问题描述

我有一个充当OAuth 1.0a提供程序的Web服务. Web应用程序通过OAuth 1工作流程来访问用户资源.到目前为止一切顺利.

I have a web service that acts as a OAuth 1.0a provider. Web applications go through the OAuth 1 workflow to gain access to user resources. So far so good.

客户端Web应用程序需要与服务进行通信以满足其他需求，以交换未链接到特定用户/资源所有者的私有数据.为此，一个好主意似乎是使用OAuth2，尤其是为此专门设计的Client Credentials Grant(4.4). 通过机密客户端"(根据OAuth规范，Web应用程序属于此类)，您可以直接对客户端进行身份验证并获得访问令牌.

The client web application has the need to communicate with the service for other needs, to exchange private data NOT linked to a particular user/resource owner. For that, a good idea seems to use OAuth2, in particular Client Credentials Grant (4.4)(which was designed exactly for this). From a "confidential client" (and a web application falls into this category, according to the OAuth specs) you can directly authenticate your client and get an access token.

当然，我要谈论的Web应用程序是html + javascript BUT身份验证，并且与提供程序/Web服务的通信完全在服务器端进行.凭据(客户端机密，密钥等)都存储在服务器上(并且永远不会离开服务器).

of course, the kind of web application I am talking about is html+javascript BUT authentication and communication with the provider/web service happens entirely server-side. Credentials (client secret, keys, etc.) are all stored on (and never leave) the server.

根据规范，可以使用用户名+密码"(具有HTTP Basic身份验证方案的客户端密码)或其他授权方法"进行身份验证.

According to the specs, authentication can happen with "username+password" (client password with HTTP Basic authentication scheme) or "other authorization methods".

我找不到这些其他授权方法"可能是什么的线索. 由于我们将私钥/公钥对用于OAuth1，因此我们也可以将它们用于此任务吗? 在这一点上，规格看起来非常宽松(而且非常含糊！).

I was not able to find any clue of what these "other authorization methods" may be. Since we use private/public key pairs for OAuth1, can we use them for this task too? The specs seem very liberal (and very vague!) on this point.

我想要各种库所支持的内容，以便第三方客户端可以使用标准库(例如DotNetOpenAuth)轻松实现它.如果需要，可以合理地假设需要对自定义方法进行一些编码，只要它可以容纳现有的库(插件?)

I would like something that is supported by the various libraries, so that a 3rd party client can implement it easily using standard libraries (like DotNetOpenAuth for example). If needed, it is reasonable to assume that some coding needs to be done for the custom method, as long as it can accommodate existing libraries (plugin?)

对于OAuth 2身份验证，除了HTTP Basic以外，是否还有任何标准"或易于使用的内容?

Is there anything "standard" or easily usable other than HTTP Basic, for OAuth 2 authentication?

推荐答案

如果是通过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.

这篇关于OAuth2不同的客户端身份验证方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！