Replies: 3 comments 3 replies
-
I fully support this suggestion. Enabling OIDC federation between GitHub.com and npmjs.com would be incredibly beneficial, similar to how PyPI handles it: Configuring OpenID Connect in PyPI. Our specific use case involves multiple repositories managed by different teams, all releasing packages under the same scope on npmjs. To manage permissions, we currently create granular access tokens and distribute them to the GitHub Actions Secrets of individual repositories. Since these granular access tokens cannot be created via API, the process must be done manually, including the manual rotation of these tokens, which is cumbersome. Additionally, I would like to highlight a notable feature of the PyPI setup: the ability to configure OIDC for a not yet existing package. With npmjs.com, you must first create a dummy version before generating a granular access token for the package. If OIDC is implemented, it would be fantastic if we could directly set it up for packages that don't yet exist. |
Beta Was this translation helpful? Give feedback.
-
I would even go as far as suggesting that npmjs.com should be able to understand the actual GITHUB_TOKEN if granted I would have expected more integration since npm has been acquired some five years ago. (In my use-case, I'd still prefer to use npmjs registry for continuity instead of pkg.gh, but am not really willing to manage isolated users, permissions, accounts etc. separately there — and would love to just link the npmjs packages to the gh repos, and let the access controls there do their magic regarding teams, granular permissions, automation tokens etc. — eventually be just able to publish with GITHUB_TOKEN in CI…) |
Beta Was this translation helpful? Give feedback.
-
How can we help move this forward? The current publishing workflow is quite dangerous, I think we can all agree on that one. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Motivation: Authentication flows are more and more secret-free / secret-less. OIDC provides a way to say in simple terms:
allow publishing from GitHub repository github.com/foo/bar with branch 'main' to a new NPM version
.This is similar to how the authentication flow from GitHub Actions to Azure works and is recommended nowadays. There you set the OIDC subject to a similar value.
Similar to npm/feedback#872
Scope: npmjs.com
Beta Was this translation helpful? Give feedback.
All reactions