Background: We use Bitbucket Server (soon to upgrade/switch to Bitbucket DataCenter). In our authentication setup, we have user passwords disabled (web auth is via a different means), so for Bitbucket/Git purposes, we use Bitbucket Personal Access Tokens (PAT). (SSH key authentication is not an option in our organization.) For cloning/pushing/etc., we have been using our username and PAT when prompted for credentials. This works, but for reasons I can't get into regarding our authentication setup, it is creating performance issues related to our automated builds and also large user-interactive local builds.
Rather than use HTTP(S) Basic authentication, Bitbucket also supports HTTP(S) Bearer token authentication, where you supply just the PAT without the username. Doing this solves our performance issues. Doing so on REST API requests is easy. Doing so on Git is trickier. This Bitbucket documentation recommends doing this:
$ git clone -c http.extraHeader='Authorization: Bearer xxxx' https://bitbucketserver.com/scm/projectname/teamsinspace.git
This works! But it exposes the PAT to others via command history, etc. A more secure variety that doesn't expose the PAT also works:
$ git clone --config-env=http.extraHeader=GIT_AUTHORIZATION_HEADER https://bitbucketserver.com/scm/projectname/teamsinspace.git
Where GIT_AUTHORIZATION_HEADER
is Authorization: Bearer xxxx
. But this still has some downsides, namely that it can't employ .gitconfig
and must be added to every command, and that users have to configure this ahead of time and can't be prompted to enter the PAT that gets stored securely in the Git credential helper.
GitLab provides a "magic username," OAuth2
, that can be provided with the token through Basic authentication that essentially tells the server "ignore the username, authenticate with the token only." Bitbucket also provides a similar "magic username," x-token-auth
, but it appears to either be Cloud-only or limited to Repository Access Tokens or both, because we have tried to use it and it just results in authentication errors. Access to such a feature would allow us to hard-code the magic username in .gitconfig
and the developer would merely get prompted for the "password for x-token-auth@our-server.com," which would be the PAT. But, alas, we can't use this feature.
About 14 years ago there was a discussion on a Git mailing list about supporting Bearer token authentication, and even a patch proposed, but it doesn't look like it ever went anywhere. I could, in theory, apply a modernized version of that patch and recompile Git, but that is really not an ideal solution for our developer organization.
I looked into creating a Git credential helper (which I've actually created before for other reasons) and a Git host provider, but everything credential-related baked into Git is hard-coded to username/password only, so those don't work.
So what I'm looking for / hoping for is some kind of way to create a helper, provider, or plugin of some type that will be able to specify, override, or replace the HTTP Authorization
header to make it Bearer instead of Basic, either using the password that comes from built-in Git credential stuff or prompting for something new if necessary, without having to compile our own customized Git fork. Is this at all possible, or should I just give up and use --config-env
?