Question

在OAuth 1.0中，2-legged非常容易：只需照常发送请求并省略access_token标题。

OAuth 2.0中的情况似乎发生了变化（如今我发现:)（）。在OAuth 2.0中，请求不再包含诸如nonce，使用者密钥，时间戳等标题。这只是替换为：

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

我了解三脚授权如何在OAuth 2.0和应用程序流程中发挥作用。但是如何在2.0版本中进行双腿工作？是否可以设计一个既能支持2脚和3脚OAuth 2.0的API呢？

我一直在寻找有关这方面的信息，但我已经找到了很多关于1.0的两条腿的东西，几乎没有2.0的东西。

Answer 1

经过大量研究后，我发现client_credentials授权类型适用于此场景。将此术语打入谷歌后，您可以找到大量非常有用的资源。

这是3脚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实施双腿OAuth 2.0的应用程序流程，显着简化：

在这种方法中，我们不需要执行任何身份验证。
我们只需使用以下表单数据发布到/oauth/token：
```
grant_type=client_credentials&scope=view_friends
```

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

这导致以下警告：

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

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

发布到/oauth/token以获取您的令牌。

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

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

在/token端点中，如果使用JWT，则只需检查grant_type的GET参数中urn:ietf:params:oauth:grant-type:jwt-bearer的值，或者对于client_credentials，只需检查client_credentials。

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

Answer 2

您还可以查看Google对2-legged OAuth2的实施情况（我相信此文档最近才发布）。

Google Drive SDK delegation docs还应该有助于了解Google的两条腿OAuth2实施。