The doc page says

For project or repository tokens, we recommend only using Bearer Auth without your username

but above that also:

For Git operations, you can use your user's access token as a substitute for your password.

so, it seems the special header is recommended but not required.

-c http.extraHeader=<Bearer Token Header here> may work with the command-line git executable, but does the Git Client plugin of Jenkins provide an API for setting this, or would that have to be changed too? How about JGit?

What feature do you want to see added?

Bitbucket Datacenter enables the creation of access token on a repository or organization level. These token are very useful, to give Jenkins e.g. read or write access to a single repository. You no longer need a god user that can read all your repositories or need to create on jenkins user in bitbucket for each repo which can really dig into your user quota.

Bitbucket Doc regarding HTTP Access Tokens: https://confluence.atlassian.com/bitbucketserver0718/http-access-tokens-1097182514.html#HTTPaccesstokens-CreateHTTPaccesstokensforprojectsorrepositories

When using the bitbucket API they can be used as a value for the bearer token header and the plugin to date already allows using them as credentials to e.g. find repos.

Currently missing is the support to use these HTTP access tokens for git clone/checkout. They need to be provided to the invocation of git as an extra header through the -c http.extraHeader=<Bearer Token Header here> flag. An example of this can be found right on the bottom of the Bitbucket Documentation mentioned above.

I could see a possible implementation of this feature in the same way you can currently select Checkout via SSH as a Git Behaviour. If I understand the documentation correctly it would also enable using this feature with personal access tokens which (as far as the current documentation describes it) cannot be used for this yet.

I hope to hear from you

Upstream changes

No response

I support @nilsmahlstaedt request.

The Git Client Plugin doesn't support it currently: https://issues.jenkins.io/browse/JENKINS-70897

Does git -c http.extraHeader=… cover Git LFS too, or would that have to be configured separately? Git LFS has tests that add extra headers to .git/config but I'm not sure it can grab the value from the -c option.

Oh also, -c on the Git command line might be visible to other users of the computer, so placing credentials there can be insecure if you run Jenkins agents on a multiuser machine.

Regarding the needed changes to the git-client-plugin

After a first look there is only a single place that would need changes in the GitCliClient.
The launchCommandWithCredentials method already handles SSHUserPrivateKey Creds and StandardUsernamePasswordCredentials. We would only need to add an additional branch for String/Secret Text Credentials.
The method builds the arg list, so a -c option could trivially be added.
The Credentials used can be added to the git client as default credentials or on a per-host basis

An alternative method to the -c flag can be environment vars for git versions >=2.31
As per git-config doc you can set up an env var config like this

GIT_CONFIG_COUNT=0
GIT_CONFIG_KEY_0=http.extraHeader
GIT_CONFIG_VALUE_0="Authorization: Bearer <TOKEN>"
git clone <REPO>

This is the equivalent of git -c "http.extraHeader=Authorization: Bearer <TOKEN>" clone <REPO> just without exposing the token to ps or comparable tools. For git verions <2.31 these environment variables are ignored.

Using this setup inside of a pipeline might theoretically be possible like this:

// inside of stage and step closure
withCredentials([string(credentialsId: '<CRED_ID>', variable: 'TOKEN')]) {
    withEnv(['GIT_CONFIG_COUNT=1', 'GIT_CONFIG_KEY_0=http.extraHeader', "GIT_CONFIG_VALUE_0=Authorization: Bearer $TOKEN"]) {
        checkout scm
    }
}

The problem you run into when using this is, while it should authenticate the clone of the actual workspace, it does not affect the initial checkout of the Jenkinsfile or any Shared Library referenced. They will run into authorization problems.

A solution will have to consider these steps plus the option of controller-agent-setup's

Does git -c http.extraHeader=… cover Git LFS too, or would that have to be configured separately? Git LFS has tests that add extra headers to .git/config but I'm not sure it can grab the value from the -c option.

It should, while testing the configuration of extraHeader through ENV Vars i used git config --list a lot to show me the combined config git is currently using. The output seemed to be the same whether I set extraHeader through one of git's config files, ENV Vars or CLI Flags.

A maintainer of Git LFS advises against using http.extraHeader for authentication: git-lfs/git-lfs#5373 (comment)