Open joelverhagen opened 1 year ago
This would be a huge win! Do you know how the client will acquire the token? Also, how will the client provide the token to the server? It'd be wonderful if the client implementation is package source agnostic so that other server implementations can leverage this too!
Do you know how the client will acquire the token?
Generally speaking, I think this would be environment (agent) specific. GitHub Actions has an SDK that allows you to fetch a token in the context of a GitHub Actions workflow run. I think this would be different on other platforms like Azure DevOps. But I'm not 100% sure yet.
Also, how will the client provide the token to the server?
I am not sure if I want it in the X-NuGet-ApiKey
header (and therefore able to be plumbed into existing versions of NuGet client as an API key) or a new configuration value instructing the client to send a Authorization: Bearer ...
header. Currently, I am leaning towards X-NuGet-ApiKey
since the ship has already sailed on having a customer NuGet auth header so we might as well use it.
It'd be wonderful if the client implementation is package source agnostic so that other server implementations can leverage this too!
Yes, this idea uses the existing protocol or enhances it in a straightforward, package source-agnostic way.
Just thought I should share this https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/. Python's PyPI has added support for OIDC authentication and has made pushing PyPI packages through GitHub Actions super simple with no token management needed. It would be great if this was also supported by NuGetGallery. I personally like the fact that PyPI uses the workflow name for the claim as I find using a branch/tag/environment not too helpful with my workflow if they don't support pattern matching (Azure does not).
Related Problem
Currently, there are only two ways to do package management operations (push new version, unlist, relist) on NuGet.org:
The first option is fine for interactive, manual flows. The second (API keys) is reasonable for automation but it has some drawbacks:
The Elevator Pitch
I propose that we enable an additional authentication method for NuGet.org protected operations: OpenID Connect bearer token-based authentication.
Currently, some web services allow OpenID Connect federated credentials. For example, you can use a GitHub OIDC token to authenticate as an Azure Active Directory (AAD) app registration: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc.
We could enable a similar flow on NuGet.org, with a UI like this (specific to GitHub OIDC tokens in this case):![image](https://user-images.githubusercontent.com/94054/208965264-30d9cc09-69e9-4873-b6db-3d42e0877d2a.png)
This would allow you to perform privileged NuGet.org actions in a GitHub Actions workflow without the need for saving an API key as a GitHub Actions secret.
We could start with GitHub OIDC and expand the offering in the future to an arbitrary OIDC provider, configured into your NuGet.org user account.
Additional Context and Details
My understanding is that npm folks are talking about a similar approach.