[Feature]: OpenID Connect (OIDC) auth for package management operations (aka Trusted Publishers)

[joelverhagen]

Related Problem

Currently, there are only two ways to do package management operations (push new version, unlist, relist) on NuGet.org:

1. Sign into the website using a web browser and perform the actions manually.
2. Use an API key to perform some operations.

The first option is fine for interactive, manual flows. The second (API keys) is reasonable for automation but it has some drawbacks:

• API keys can be leaked or stolen, leading to unauthorized actions potentially compromising your package consumers.
• API keys expire and must be manually rotated from time to time (max 1 year).

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):

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

• Main OpenSSF recommendation: https://repos.openssf.org/trusted-publishers-for-all-package-repositories
• AAD OIDC integration: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc
• GitHub OIDC: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect

My understanding is that npm folks are talking about a similar approach.

[loic-sharma]

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!

[joelverhagen]

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.

[jborean93]

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).