OAuth 2.0中的双腿oauth如何工作?

在OAuth 1.0中,双腿非常容易:只需像往常一样发送请求,并省略access_token标头。

事情似乎已经在OAuth 2.0中发生了变化(很显然,正如我今天发现的:))。 在OAuth 2.0中,请求不再具有诸如随机数,消费者密钥,时间戳等的标题。这仅仅被replace为:

 Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh 

我了解3种一站式授权在OAuth 2.0和应用程序stream程中的工作原理。 但是2.0版本中的两条腿怎么样? 是否可以devise一个既可以支持两脚也可以支持三脚的OAuth 2.0的API?

我一直在寻找关于这方面的信息,但我一直在寻找1.0的很多东西,2.0几乎没有。

经过大量研究,我发现client_credentials授权types是针对这种情况的。 一旦你在谷歌这个术语,你可以find大量非常有用的资源。

这是三脚OAuth 2.0的正常stream程(我们希望用户login):

假设我们的应用程序中有以下terminal进行身份validation:

 /oauth/auth /oauth/token 

通常(授权代码授权),我们将用户/oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

然后在authentication后,用户被redirect到mysite.com/blah?code=somecode

然后我们得到一些somecode并使用/oauth/token?code=somecode&client_id=myid&client_secret=mysecret交换它的/oauth/token?code=somecode&client_id=myid&client_secret=mysecret

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


这是client_credentials实现双腿OAuth 2.0的应用程序stream程,明显更简单:

  • 在这种方法中,我们不需要执行任何validation。
  • 我们只需使用以下表单数据发送到/oauth/token

     grant_type=client_credentials&scope=view_friends 

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

这导致以下警告:

  • 只用于(非常)可信的应用程序,如内部应用程序。
  • 你需要设备自己的方式进行身份validation。 例如, RFC的例子使用基本身份validation。

另一个解决scheme是使用像谷歌的OAuth API JWT(JSONnetworking令牌)。 这是一个非常复杂的过程,但是存在大量的用于生成JWT的库。 然后您发布以下表单数据(当然编码的url):

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

这是张贴到/oauth/token来得到你的令牌。


至于是否可以创build一个支持2-legged和3-legged OAuth 2.0的API是的,这是可能的

那么/auth端点仅在用户需要对服务进行authentication时才使用。

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

请注意,在生成client_id和client_secret以提供给用户时,如果您支持多个grant_types ,请确保您有一个数据库列来存储为其生成的id和secret的授予types。 如果要求每个用户拥有多个授权types,请为每个授予types生成一组不同的凭证。

您还可以查看Google的双腿OAuth2的实现(我相信这个文档最近才发布)。

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

Interesting Posts