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 (closed).
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:
- 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.
- 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
- Headers
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.