两条腿的oauth如何在OAuth 2.0中运行？

Question

在OAuth 1.0中,2-legged非常容易:只需像往常一样发送请求并省略access_token标题.

OAuth 2.0中的情况似乎已经发生了变化(我今天发现了很多:)).在OAuth 2.0中,请求不再具有诸如nonce,使用者密钥,时间戳等的标头.这只是替换为:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

我理解3脚授权如何在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实现2脚OAuth 2.0 的应用程序流程,它显着简化:

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

• 我们只需/oauth/token使用以下表单数据POST :

  grant_type=client_credentials&scope=view_friends
  

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

这导致以下警告:

• 仅用于(非常非常)受信任的应用程序,例如内部应用程序.
• 您需要以自己的方式进行身份验证.例如,RFC的示例使用基本身份验证.

另一种解决方案是使用JWT(JSON网络令牌),例如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端点中,只需检查grant_typeGET参数中的值urn:ietf:params:oauth:grant-type:jwt-bearer是否使用JWT或client_credentialsclient_credentials.

需要注意的是产生CLIENT_ID和client_secret给用户,如果你是支持多个时grant_types,请确保您有一个数据库列来存储哪种类型的授输入ID和生成的秘密.如果每个用户需要多个授权类型,请为每个授权类型生成一组不同的凭据.