56

在 OAuth 1.0 中，2-legged 非常容易：只需像往常一样发送请求并省略access_token标头。

OAuth 2.0 中的情况似乎发生了变化（正如我今天发现的那样：)）。在 OAuth 2.0 中，请求不再有诸如随机数、消费者密钥、时间戳等标头。这只是替换为：

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

我了解 OAuth 2.0 和应用程序流程中的 3 条腿授权如何工作。但是 2-legged 在 2.0 中是如何工作的呢？是否可以设计一个同时支持 2-legged 和 3-legged OAuth 2.0 的 API？

我一直在寻找有关这方面的信息，但我在 1.0 的 2-legged 上找到了很多东西，而 2.0 几乎没有。

4

2 回答 2

79

经过大量研究，我发现client_credentials授予类型适用于这种情况。一旦你把这个词打进谷歌，你会发现很多非常有用的资源。

这是 3-legged OAuth 2.0 的正常流程（我们希望用户登录）：

假设我们的应用中有以下端点用于身份验证：

/oauth/auth

/oauth/token

通常（对于授权码授予），我们指导用户/oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

然后在认证后，用户被重定向到mysite.com/blah?code=somecode

然后我们somecode使用/oauth/token?code=somecode&client_id=myid&client_secret=mysecret

然后我们可以使用令牌进行调用。

这是client_credentials实现 2-legged OAuth 2.0 的应用程序流程，它明显更简单：

  • 在这种方法中，我们不需要执行任何身份验证。

  • 我们只需 POST 到/oauth/token以下表单数据：

     grant_type=client_credentials&scope=view_friends

请注意，范围是可选的。然后端点直接返回一个访问令牌供我们使用（不提供刷新令牌）。由于没有提供刷新令牌，因此当令牌过期时，您将需要重新进行身份验证并请求一个新令牌。

这导致以下警告：

  • 仅将其用于（非常非常）受信任的应用程序，例如内部应用程序。
  • 您需要设计自己的身份验证方式。例如，RFC 的示例使用基本身份验证。

另一种解决方案是使用 JWT（JSON Web 令牌），例如google OAuth API。这是一个非常复杂的过程，但是存在许多用于生成 JWT 的库。然后，您发布以下表单数据（当然是 url 编码）：

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt

这是/oauth/token为了获取您的令牌而发布的。

至于是否可以创建支持 2-legged 和 3-legged OAuth 2.0 的 API的问题，是的，可以。

然后/auth端点仅在用户需要对服务进行身份验证时使用。

在/token端点中，只需检查grant_typeGET 参数中的值urn:ietf:params:oauth:grant-type:jwt-bearer是否使用 JWT 或client_credentialsclient_credentials。

请注意，在生成 client_id 和 client_secret 以提供给用户时，如果您支持 multiple grant_types，请确保您有一个数据库列来存储生成 id 和 secret 的授权类型。如果需要为每个用户提供多种授权类型，请为每种授权类型生成一组不同的凭据。

于 2013-01-10T05:03:55.713 回答
2

您还可以查看 Google 的2-legged OAuth2实现（我相信该文档最近才发布）。

Google Drive SDK 委托文档也应该有助于理解 Google的2-legged OAuth2 实现。

于 2013-11-22T02:11:30.993 回答