Support Bearer Authentication for Package Registry

[mcmitch]

Summary

Add support for the use of bearer authentication for package registry. This is to support the use of oauth2 authentication to a private Gitlab PyPy registry via a custom keyring provider. Currently having to use private access tokens to authenticate.

This works:

curl --header "Authorization: Bearer <oauth2_token>" "https://gitlab<self-host>.com/api/v4/groups/<package>/-/packages/pypi/simple/"

This does not work:

curl -u "oauth2:<oauth2_token>" "https://gitlab<self-host>.com/api/v4/groups/<package>/-/packages/pypi/simple/"

Example

No response

[mcmitch]

Restriction seems to be in https://github.com/astral-sh/uv/blob/main/crates/uv-auth/src/keyring.rs#L258, where it always maps to basic authentication.

[woodruffw]

Hi @mcmitch, can you provide some more details about your authentication setup? To my understanding pip itself has only ever supported basic authentication, so Python packaging as an ecosystem has generally unified around it. I also can't find a ton of docs on GitLab's PyPI-style index's support for OAuth2 access tokens; these docs suggest that OAuth2 access tokens aren't supported officially on GitLab's side either for their PyPI-style service.

[mcmitch]

The gitlab deployment is setup to require PAT or oauth2 for git access, where PAT have a maximum lifetime enforced. Use of oauth2 for the package registry would provide an improved user experience, where users don't have to manually generate or store new PAT for this.

The gitlab position around official support is not clear, but https://gitlab.com/gitlab-org/gitlab/-/work_items/444856 is currently opened. The workaround of using a bearer token was suggested and I have confirmed this works on our deployment. I have created a custom plugin for keyring which is able to get an oauth2 access token, but currently there is no way to pass this to UV to use for authenticating the registry via token authentication as basic auth does not work with oauth2.

This possibly is a duplication on #1369 although it is a bit more specific, as my key requirement is around the integration with keyring

[woodruffw]

OK, thanks. I think there are two things here:

1. Ideally, GitLab could clarify the status/intended support level of what you're doing. I think uv shouldn't add an authentication mechanism (particularly one pip doesn't use) unless we get a strong commitment/communication from an index that they won't just remove it in the future as unintentional.
2. Separately, GitLab should allow you to pass your OAuth2 access token via basic authentication, in addition to the normal (more idiomatic) bearer authentication. This would be maximally compatible with what all Python installers currently do, and wouldn't require any additional changes to uv. To my understanding this is what some other index services (like Google Artifact Registry) do with their OAuth2 access tokens (they do oauth2accesstoken:<token> as the pair).

[mcmitch]

Having done a bit more digging, I think you are right, and python-poetry/poetry#10037 (comment) probably summarizes it quite well. It is something that keeps coming up, but it is a niche requirement.

While there is a pull request for a PEP, python/peps#3172, it isn't yet a draft.

At the time of opening the enhancement, I had not appreciated that the auth mechanism was implicit in the PyPy standard, and had assumed that the underlying authentication mechanism was flexible although predominately basic auth.