Allow using Bitbucket Cloud API Token for authorization

[verbalius]

Bitbucket deprecated app paswords and tells users to use API tokens instead. But API tokens (for example repo api tokens) they don't work with username:password scheme where username is the bot email. This pull request changes auth to NewOAuthbearerToken if the username is x-api-token-auth or x-bitbucket-api-token-auth as Bitbucket tells in the documentation.
https://developer.atlassian.com/cloud/bitbucket/rest/intro/#app-passwords

Before the change I was always getting the 401 error (tried various combinations of email, username, personal tokens and repo tokens)

After a change it works

[matheuscscp]

We do not need to establish these special values for username in order to branch off the code to bitbucket.NewOAuthbearerToken(). The Provider API supports standalone token inputs that do not depend on a username being specified. In fact, the bitbucket provider is already using such token input and breaking it down into username and password:

	comp := strings.Split(token, ":")
	if len(comp) != 2 {
		return nil, errors.New("invalid token format, expected to be <user>:<password>")
	}
	username := comp[0]
	password := comp[1]

This is very unfortunate, because we also support username+password inputs in the referenced secret.

@verbalius How is bitbucket handling this deprecation? Has username+password stopped working completely? I ask this because I'd like to fix this code to do the right thing (if token is set, use bitbucket.NewOAuthbearerToken(); if user+pass is set, use bitbucket.NewBasicAuth()), but this would be a breaking change. The Provider API is still v1beta3 so maybe this is still possible (esp. given this move from bitbucket).

@stefanprodan Thoughts?

[verbalius]

@matheuscscp Hi, Matheus! Thanks for looking at this pull request.
Yeah I tried using bitbucket api token with email as they say in the documentation, and various other combinations but nothing worked until I did the change and built my own image and deployed to private repo for time being.
In this pull request I tried to not break any other clients that are configured in the older way if they still have the app password active (Bitbucket is still keeping them till some time of expiration, not sure by when, because I have some app passwords that don't have expiration day) but I agree that it's better to implement it better in a new way.

[thomasspear-wcg]

Hi team,

I'm having trouble getting notifications working with bitbucket right now and suspect that the app password deprecation is responsible. I'm not getting any log output even at the debug log level to indicate that the provider is working, not seeing any status updates in bitbucket, and also not seeing any denied traffic from the notification controller pod in my org's firewall.

https://developer.atlassian.com/cloud/bitbucket/rest/intro/#app-passwords says that app passwords are deprecated from last September. I also found this elsewhere (emphasis is mine):

Bitbucket Cloud app passwords will be permanently disabled on June 9, 2026. As part of a security transition, creating new app passwords will be disabled on September 9, 2025. Existing app passwords will continue to function until the final 2026 deadline, but users are advised to transition to API tokens for enhanced security and centralized control.

That being said, Bitbucket still supports HTTP basic auth for username+password, where the username is the user's email and the password is an api token. So I wonder, then, is the right thing to do, configure the secret to use key names username and password instead of a single colon-separated username/password value in a key named token? It appears to apparently also still support HTTP basic auth for username+password where the username is x-token-auth and the password is a repo, project, or workspace access token.

I did try both token and username/password fields in the secret with a real user account in bitbucket but no success so far finding any status in bitbucket nor even logs in notification controller about the events I want to send to bitbucket. Incoming events are being processed by our bitbucket receiver without issues but the provider doesn't seem to be working in my case.