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)
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
Hi Patrik. Are you certain? I tried Authorization Code Grant at
oauth2: "unauthorized_client" "Client credentials missing; this request needs to be authenticated with the OAuth client id and secret"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.