Unexpected HTML response from OAuth2 /access_token endpoint



I am attempting to exchange an OAuth2 code for an access token.

Here is how I have implemented this:

  • Send the user to [https://]bitbucket[dot]org/site/oauth2/authorize?response_type=code&client_id=<myid>&state=<mystate>
  • Receive code and state at my callback endpoint (working perfectly thusfar)
  • Make a POST request to exchange code for token to [https://]bitbucket[dot]org/site/oauth2/access_token?code=<code>&grant_type=authorization_code (with the Authentication header set to Bearer <client_id>:<secret> with the value being base64-encoded of course)

My understanding of the OAuth on Bitbucket Cloud document (and the OAuth2 authorization code grant flow) indicates to this being correct but clearly something is wrong.

Instead of getting back JSON with my token, refresh token, etc. I get HTML back that mentions OpenID transaction in progress which makes me think I’m doing something incorrectly.

I can dig up the exact HTML if necessary.

I am not using a pre-packaged OAuth2 client implementation (I am writing this myself).

Please let me know if I have misunderstood the linked documentation in any way.
This is, unfortunately, blocking me from continuing development of a Bitbucket Cloud addon.

Any help is much appreciated!

Note for support team: This is in reference to https://twitter.com/Phrohdoh/status/1026230161589645313.

Edit: I changed the URLs I am hitting to be a bit uglier ("[dot]" and “[https://]”) so I could include other links (I am a new member here and am limited in the number of links I can share so far).


Hi Taryn,

Sorry the docs aren’t completely clear here. You’re doing the right thing by base64 encoding the <client_id>: but when you do that, the auth scheme should be set to Basic instead of Bearer. Bearer is used to indicate that you’re using a bearer token that you were handed back from the service. Once you have retrieved an access token, you should use Authorization: Bearer <access_token> to authenticate requests. OAuth treats the client_id/secret as the username/password for basic auth.

In addition to the Bitbucket docs, you may want to take a look at the spec itself. Bitbucket tries to follow the spec as closely as possible. That request is documented here: https://tools.ietf.org/html/rfc6749#section-4.1.3. where you can see an example of Basic auth being used.

Returning HTML because of that isn’t a great developer experience. We’ll see if we can get that cleaned up so other people don’t run into the same problem in the future.


Ahh thank you so much!
Of course it is basic auth, bearer doesn’t make sense there for the exact reason you’ve explained.

I was overlooking that every single time.
Thanks again.

I will make that change and go through the flow again.