3

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.

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.

EDIT: 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.

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

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.

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?)

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

4

1 回答 1

2

如果您所说的 Web 应用程序是指在客户端浏览器中运行并需要向您的服务发出安全请求的 JavaScript 和 HTML 应用程序，那么这不是“机密客户端”。您不能将机密存储在基于浏览器的应用程序中，因为它们对所有人都是可见的。

如果您所说的 Web 应用程序是指需要发出服务器到服务器请求的服务器端应用程序，那么这就是“机密客户端”，因为执行代码和机密信息无法供公众审查。

我将“其他身份验证方法”解释为可以在一个请求中完成的通过 http（或 https）惯用的任何身份验证方案。使用 TLS 的客户端证书身份验证也可能属于此存储桶。我认为 OAuth2 4.4 Client Credentials Grant 的主要部分是客户端应用程序通过现有的身份验证方法直接向 OAuth 令牌服务提供凭据。该示例使用 HTTP Basic 身份验证，但这只是一个示例。

客户端凭据授予与资源​​所有者凭据授予 (4.3) 的不同之处主要在于资源所有者授予在 http 请求的正文中而不是在授权标头中提供用户凭据。在资源所有者授权的情况下使用其他授权方法会很困难。

将其他身份验证方法与 Client Credentials Grant 一起使用的最大警告是，OAuth2 客户端库对 HTTP Basic 身份验证以外的任何内容的支持最多可能是参差不齐的。即使您将摘要或客户端证书身份验证与客户端凭据一起使用在 OAuth2 规范内，我仍然怀疑现有的 OAuth2 客户端库是否会对您的特定排列提供内置支持。看看您是否可以找到一些大玩家（例如 Google 或 Yahoo）使用 HTTP Basic auth 以外的任何方式授予客户端凭据的示例。那里使用的东西更有可能得到 OAuth 客户端库的支持（尤其是他们发布的库！）。

如果您拥有连接的两端，这并不重要。你可以做任何你想做的事情，并找到一个客户端库，它可以让你调整或定制请求以满足你的需求。

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

于 2013-08-06T17:04:10.077 回答