在OAuth 1.0中，两条腿很容易:只需像往常一样发送请求并省略access_token标头。
事情似乎在OAuth 2.0中发生了变化(正如我今天发现的那样，变化很大:))。在OAuth 2.0中，请求不再具有nonce、消费者密钥、时间戳等标头。它被替换为:
Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh
我了解在OAuth 2.0和应用程序流中3条腿的授权是如何工作的。但是在2.0中两条腿是如何工作的呢?是否有可能设计一个API，可以同时支持两条腿和三条腿的OAuth 2.0?
我一直在寻找关于这方面的信息，但是我已经找到了很多关于1.0的2- legs的东西，而几乎没有关于2.0的东西。
经过大量研究，我发现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实现2腿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腿和3腿OAuth 2.0的API的问题， 可以，。。
那么/auth端点仅在用户需要对服务进行身份验证时使用。
在/token端点中，如果对client_credentials使用JWT或client_credentials，只需在urn:ietf:params:oauth:grant-type:jwt-bearer的GET参数中检查grant_type的值。
请注意，在生成要给用户的client_id和client_secret时，如果您支持多个grant_types，请确保您有一个数据库列来存储生成id和secret的授权类型。如果需要每个用户有多个授权类型，则为每种授权类型生成一组不同的凭据。
您还可以查看Google的2腿OAuth2实现(我相信这个文档是最近才发布的)。
Google Drive SDK委托文档也应该有助于理解Google的2腿OAuth2实现。