Draft: Exhaustively test authentication mechanisms for package manager APIs

What does this MR do and why?

This MR is based on !50729 (closed), which is a community contribution that I'm taking across the finish line as per !50729 (comment 754193655).

Closes #347410.

Original description with minor modifications to reflect discussion from original MR follows:

This MR adds a spec file that tests package manager APIs against a matrix of authentication transport mechanisms and credential types. For each package manager, for each supported scope (project, group, and/or instance), one API endpoint is tested. This will serve two purposes:

1. At first, it will paint a clear picture of which auth mechanisms are currently available and make it easier to catch any unintended modifications. The results from this exercise have helped find that most package manager APIs allow a far broader range of auth pathways than expected and documented.
2. Then, as each package manager API is updated to reduce the available auth mechanisms to a desired officially supported minimum (see &3807), the specs will be updated and serve as proof that unnecessary doors are being removed.

• Credential types
  • OAuth access token
  • Personal access token
  • CI job token
  • Deploy token
• Authentication transport mechanisms
  • Headers
    • Authorization, Basic
    • Authorization, Bearer
    • Private-Token
    • Job-Token
    • Deploy-Token
  • Query parameters
    • token
    • access_token
    • bearer_token
    • private_token
    • job_token
    • deploy_token

Note: The spec does not yet support the Debian repository (because I skipped it).

Note: The spec does not yet check for Conan-specific authentication logic.

Results

This has been left unmodified from original MR.

The following shows accepted credentials types and transport mechanisms for each package manager API:

	Maven	NPM	Conan	NuGet	PyPI	Composer	Generic	Go proxy
Authorization: Basic	Deploy	Deploy	PAT, Job, Deploy	PAT, Job, Deploy	PAT, Job, Deploy	OAuth, PAT, Job, Deploy		PAT
Authorization: Bearer	OAuth, PAT, Job, Deploy	OAuth, PAT, Job, Deploy	Job		OAuth, PAT, Job, Deploy	OAuth, PAT	OAuth, PAT, Job	OAuth, PAT, Job
Private-Token:	PAT	PAT			PAT	PAT	PAT	PAT
Job-Token:	Job	Job				OAuth†, PAT†, Job†, Deploy†	Job	Job
Deploy-Token:	Deploy	Deploy			Deploy	OAuth, PAT, Job, Deploy
token=	Job	Job				OAuth†, PAT†, Job†, Deploy†	Job	Job
access_token=	OAuth, PAT, Job, Deploy	OAuth, PAT, Job, Deploy	Job		OAuth, PAT, Job, Deploy	OAuth, PAT	OAuth, PAT, Job	OAuth, PAT, Job
bearer_token=	OAuth, PAT, Job, Deploy	OAuth, PAT, Job, Deploy	Job		OAuth, PAT, Job, Deploy	OAuth, PAT	OAuth, PAT, Job	OAuth, PAT, Job
private_token=	PAT	PAT			PAT	PAT	PAT	PAT
job_token=	Job	Job				OAuth†, PAT†, Job†, Deploy†	Job	Job
deploy_token=						OAuth, PAT, Job, Deploy

† These credential types can be used for the project endpoint but not the group endpoint

Screenshots or screen recordings

NA

How to set up and validate locally

bin/rspec spec/requests/api/package_manager_auth_methods_spec.rb

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.