OAUTH2.0 Bearer token not working

Question

I am using retrofit 2.0 to build a Bitbucket REST client on Android.

As far as I'm concerned, OAUTH2.0 provides "Implicit grant" which gives the client the access Bearer token immediately when the user logins to their account when are prompted to.

Bearer tokens are tokens that can be used to access protected resource. Anyone who has a bearer token has the permission to access the protected resource as anyone else who also has the bearer token. (according to this doc from IETF)

Please correct me if I'm wrong, but I thought using implicit grant, after user logins in their Bitbucket account, I will have the Bearer access token. After that, I can use this access token to access protected resource on Bitbucket (like create a new repository).

So I have built my android using the OAUTH2.0 Implicit grant as described in the Bitbucket doc. Note that they described the response will have #access_token={token}&token_type=bearer

And this is what I actually received from Bitbucket after logging in:

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

My first question: What exactly is the Bearer access token from the above response?

Is the part lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw the Bearer access token? Do I have to include the "%3D" (which is the char "=" encoded in ASCII)? Doesn't the Bitbucket doc mean that everything exceptfor the last "&token_type=bear" is the Bear access token?

That's not all. Bitbucket doc's instruction to make request as follow:

Send it in a request header: Authorization: Bearer {access_token}

So I set this request up to create a new repository in accordance with the API of Bitbucket:

@POST("repositories/{username}/{repo_slug}")
    Call<Repository> createRepository(
            @Header("Authorization") String auth,
            @Path("username") String userName,
            @Path("repo_slug") String repoSlug);

But everytime, I got the respones with status code 401 and message error:

Access token expired. Use your refresh token to obtain a new access token.

When I tried to POST the same request using DHC by Restlet (a chrome extention like Postman), a pop up appears and requires me to login to Bitbucket. If I refuse to do so, I got the same error 401 response. If I do login, then it works.

My second question: Why do I have to provide my credentials again?

I think there's something wrong here. I thought with the Bearer access token, I should be able to access the protected resource without having to log in before the access token's expire time has been reached. Why do I have to enter my credentials the second time? This is not what is described in the "Implicit grant" approach here by IETF.

Answer 1

The value of the access_token starts after access_token= and ends before the next parameter scopes so before &scopes=. The formatting of the fragment part is specified in https://www.rfc-editor.org/rfc/rfc6749#section-4.2.2 which in its turn points to https://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.4.1 which says:

[...] The name is separated from the value by = and name/value pairs are separated from each other by & [...]

So your access token value by spec is lEuvneW39onVrnNR-jvZfirI43fwi5Wdc0YaaMROBk5YKJsd2ulXm20vJDdOBjf8I-Ne2r2vC8-_FHECSLw%3D but I agree that the ending %3D is suspicious and may be an error on the sender's part.

If your access token is expired (which is what it seems to be) you need to get a new one using the Implicit grant again, or using the Refresh token grant.