Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Bug: BitBucket Cloud requires OAuth secret for public clients

M H June 21, 2023

OAuth specification RFC 8252 says https://datatracker.ietf.org/doc/html/rfc8252#section-8.5

it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret

but BitBucket Cloud requires client secret for all OAuth clients, including public clients https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/

BitBucket should only require client secret for confidential clients (private consumers)

1 answer

1 accepted

1 vote
Answer accepted
Patrik S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 22, 2023

Hello @M H and thank you for reaching out to the Community!

The client secret is only necessary if you are using the client credentials grant, which requires you to also mark the checkbox private consumer when creating a new Oauth consumer under your workspace, or editing an existing one.

For the other available OAuth 2.0 authentication for Bitbucket API, you should only need the clientId of the OAuth consumer. You can have more details on which OAuth2.0 flows are supported and the corresponding RFC specification in the following documentation : 

Thank you, @M H !
Patrik S

M H June 23, 2023

Hi Patrik. Are you certain? I tried Authorization Code Grant at 

https://bitbucket.org/site/oauth2/authorize without client secret and got error: 

oauth2: "unauthorized_client" "Client credentials missing; this request needs to be authenticated with the OAuth client id and secret"

Patrik S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 27, 2023

Hello @M H ,

For the Authorization Code Grant, you will need to access the URL :

https://bitbucket.org/site/oauth2/authorize?client_id={client_id}&response_type=code

providing the clientID of the OAuth consumer created under the bitbucket workspace. This will return an authorization code in the query parameter ?code={} of the call-back URL. To exchange the code for an Access token you will indeed need to provide the clientID and secret to the access_token API endpoint : 

 curl -X POST -u "client_id:secret" https://bitbucket.org/site/oauth2/access_token -d grant_type=authorization_code -d code={code}

If you would like to avoid having to provide the secret, you may want to use the Implicit grant flow, where the access token will be returned directly in the URL fragment #access_token={token}&token_type=bearer , and you just need to provide the clientID of the Oauth consumer:

https://bitbucket.org/site/oauth2/authorize?client_id={client_id}&response_type=token

Thank you, @M H !

Patrik S

M H June 27, 2023

@Patrik S thanks for clarifying. I tested again, and confirm that secret is only required to exchange authorization code for access token.

This is nevertheless a bug -- following OAuth spec https://datatracker.ietf.org/doc/html/rfc8252#section-8.5 , client secret should not be required at all for public clients (ie. non private consumers)

it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret

Dan Fraser
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 2, 2023

Hey @M H ,

Thanks for reaching out. You're correct in your interpretation of the OAuth specifications, that is a secret is not needed for public OAuth consumers

However, I believe the reason they've stated that requiring a secret for a public consumers is `NOT RECOMMENDED` is due to the fact that it's called a secret yet it is publicly accessible as it's distributed with the app. Which I believe is confusing to users. Requiring the client id and secret for the OAuth flows on a public OAuth Consumer flow doesn't make the flow any more or less secure.

In our OAuth Consumer configuration page we state this. Screenshot 2023-07-03 at 12.51.20 pm.png

We state that shipping the consumer credentials with the app should only occur on a public consumer, and to me it's clear that if you're shipping credentials in your app, it's not a secret. But maybe this needs to be reworded to be clearer.

As this isn't a bug, more of an implementation quirk, we're unlikely to change our backend implementation to remove the need for a secret for public consumers.

Best regards,

@Dan Fraser 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
AUG Leaders

Atlassian Community Events