OAUTH2.0承载令牌无法正常工作

时间:2016-10-28 19:05:30

标签: android api oauth oauth-2.0 bitbucket-api

我正在使用retrofit 2.0在Android上构建Bitbucket REST客户端。

就我而言,OAUTH2.0提供"隐含授权"当用户在提示时登录到他们的帐户时,它会立即为客户端提供访问承载令牌。

承载令牌是可用于访问受保护资源的令牌。拥有承载令牌的任何人都有权访问受保护资源,就像拥有承载令牌的任何其他人一样。 (根据IETF的this doc

如果我错了,请纠正我,但我想使用隐式授权,用户登录他们的Bitbucket帐户后,我将获得Bearer访问令牌。之后,我可以使用此访问令牌访问Bitbucket上的受保护资源(如创建新存储库)。

所以我使用了Bitbucket doc中描述的OAUTH2.0隐式授权构建了我的机器人。请注意,他们描述了响应将具有#access_token={token}&token_type=bearer

这是我登录后实际从Bitbucket收到的内容:

your://redirecturi#access_token=lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw%3D&scopes=pipeline%3Awrite+webhook+snippet%3Awrite+wiki+issue%3Awrite+pullrequest%3Awrite+repository%3Adelete+repository%3Aadmin+project%3Awrite+team%3Awrite+account&expires_in=3600&token_type=bearer

我的第一个问题: 上述响应中的Bearer访问令牌究竟是什么?

部分lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw是否是承载访问令牌?我是否必须包含"%3D" (这是char" ="用ASCII编码)? Bitbucket doc并不意味着除了最后一个"& token_type =承担"是熊访问令牌?

那不是全部。 Bitbucket doc提出如下要求的指示:

  

在请求标头中发送:授权:Bearer {access_token}

因此,我根据API of Bitbucket

设置此请求以创建新存储库
@POST("repositories/{username}/{repo_slug}")
    Call<Repository> createRepository(
            @Header("Authorization") String auth,
            @Path("username") String userName,
            @Path("repo_slug") String repoSlug);

但每次,我都得到状态代码为401的响应和消息错误:

  

访问令牌已过期。使用刷新令牌获取新的访问令牌。

当我尝试使用Restlet的DHC(像Postman这样的Chrome扩展名)发布相同的请求时,会出现一个弹出窗口并要求我登录Bitbucket。如果我拒绝这样做,我得到了同样的错误401响应。如果我登录,那么它可以工作。

我的第二个问题:为什么我必须再次提供我的凭据?

我觉得这里有些不对劲。我认为使用Bearer访问令牌,我应该能够访问受保护的资源,而无需在访问令牌的到期时间到来之前登录。为什么我必须第二次输入我的凭证?这不是&#34;隐含授权&#34;中描述的内容。 IETF接近here

1 个答案:

答案 0 :(得分:1)

access_token的值在access_token=之后开始,在scopes之前的下一个参数&scopes=之前结束。片段部分的格式在https://tools.ietf.org/html/rfc6749#section-4.2.2中指定,而https://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.4.1又指向{{3}},其中包含:{/ p>

  

[...]名称与值=和名称/值对分开   通过& [...]

彼此分开

因此,根据规范,您的访问令牌值为lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw%3D,但我同意结尾%3D是可疑的,并且可能是发件人的错误。

如果您的访问令牌已过期(这似乎是它),您需要再次使用隐式授权或使用刷新令牌授权来获取新的令牌。