🚀 Coming Soon: OpenID Connect (OIDC) Support for npm Registry

[leobalter]

Hello npm community! 👋

We're excited to announce that we're bringing OpenID Connect (OIDC) authentication to the npm registry! This new feature will enable more secure, token-less authentication for publishing packages in your CI/CD workflows.

What's Coming?

OIDC support will allow you to publish npm packages from your CI/CD workflows without managing npm tokens. Your CI/CD provider's identity tokens will authenticate directly with the npm registry, providing:

• 🔐 Enhanced Security: No more long-lived tokens stored in your CI/CD secrets
• 🔄 Simplified Token Management: Automatic, short-lived authentication
• 🏗️ Trusted Publishing: Packages published directly from verified CI/CD workflows
• 🚀 Native CI/CD Integration: Seamless authentication in your existing pipelines

Initial Platform Support

At launch, we'll support package publishing from:

• GitHub Actions workflows
• GitLab CI/CD pipelines

We plan to expand support to additional platforms based on community feedback and demand.

Timeline

• 🔧 npm CLI Support: a PR with The CLI changes is ready (before the registry feature goes live)
• 🎯 Private Preview: June 2025 - Limited access for early testers
• 🌍 Public Release: July 2025 (tentative) - General availability for all users

Note: Timelines are subject to change based on testing and feedback during the private preview.

Get Involved!

We want to hear from you! This thread is your space to:

• 🙋 Express interest in joining the private preview
• 💭 Share feedback on the upcoming feature
• 🤔 Ask questions about OIDC implementation
• 🚀 Suggest additional platforms you'd like to see supported
• 📝 Discuss use cases for secure package publishing

Interested in the Private Preview?

If you'd like to be considered for the private preview in June, please comment below with:

1. Your use case for OIDC-based package publishing
2. Which platform you'd primarily use (GitHub Actions or GitLab)
3. How many packages you typically publish and how often

Stay Updated

We'll use this thread to share updates, documentation links, and gather feedback throughout the rollout. Make sure to watch this discussion to stay informed!

Looking forward to your feedback and building this together with the community! 🎉

---

The npm Team at GitHub

[blaine-arcjet]

Super excited for OIDC support on npm! We at Arcjet would love to be part of the private preview in June.

1. Your use case for OIDC-based package publishing

We publish the arcjet-js SDK to npm but don't currently use CI publishing due to security concerns around long-lived tokens. We also want to add build provenance which is easiest using CI publishing.

2. Which platform you'd primarily use (GitHub Actions or GitLab)

GitHub Actions.

3. How many packages you typically publish and how often

I think we're up to 33 packages now. We generally publish once or twice per month.

[arcjet-rei]

Just cosigning to say that strengthening the chain of custody and also improving Arcjet's ability to automate more steps of the publishing process would be extremely useful in making it easier for us to deploy more often and with greater confidence.

[travi]

🙋 Express interest in joining the private preview

we'd love to be involved in the preview so we can make sure semantic-release is ready for the public release.

1. ensure we can support folks publishing with the semantic-release npm plugin
2. GitHub Actions
3. we have 24 packages within the semantic-release org and publish as soon as a user-facing feature is available, including dependency updates

[travi]

from a testing perspective, https://www.npmjs.com/org/form8ion has 87 packages that are often published more often than our official semantic-release packages, so it could be helpful to also include that org so we could evaluate semantic-release changes on active packages before a stable release

[travi]

🚀 Suggest additional platforms you'd like to see supported

out of curiosity, is supporting OIDC for other registries, like Artifactory, part of the plan?

[leobalter]

We don't have specific plans for other registries at this moment. It seems like most of the support for other registries could be done directly on the cli once our public PR is ready.

[mxschmitt]

🙋 Yay! Express interest in joining the private preview

1. No need for tokens anymore / no need to refresh them. We publish our Playwright packages via NPM. Managing the tokens across different repositories is hard.
2. GitHub Actions
3. Around 20 every day

[Shegox]

I would be interested as well in the preview if you need additional tokens

1. We have a GitHub organization (SAP) and a npm organization/scope (@SAP) and different development teams with individual repositories and packages. Currently we started to centrally distribute granular npm tokens to the relevant GitHub Action Secrets using a single technical user (https://www.npmjs.com/~sap-ospo-admin). With OIDC-trust we could eliminate this token distribution and rather relay a one-time trust setup.
2. GitHub Actions
3. Currently only 7 packages with a handful of releases a month.

[spowser]

Please add Azure DevOps to the shortlist of supported CI/CD platforms. 🙏

[JamieMagee]

Here is the documentation on the OIDC token endpoint for Azure DevOps: https://learn.microsoft.com/en-gb/rest/api/azure/devops/distributedtask/oidctoken/create?view=azure-devops-rest-7.2

[tom-sherman]

Will this include using OIDC for fetching/resolving packages from the registry via OIDC? Or just publishing?

If just publishing, do you plan to support OIDC for npm i?

[dominikg]

How do you identify which npm package is allowed to be published by what repo (fork are not allowed to, right?)

How do you prevent malicious command injection in a workflow crafting a directory with malware and running npm publish ? (eg via dependency post-install script, third-party action, maybe as part of a second step after obtaining access to a reputable package used in lots of release processes...)

[janbrasna]

1. Configuring claims with the subject to be allowed: https://docs.github.com/en/actions/concepts/security/openid-connect#understanding-the-oidc-token

2. Publishing only allowed with id-token:write https://docs.github.com/en/actions/reference/security/oidc#workflow-permissions-for-the-requesting-the-oidc-token

[SuperchupuDev]

This is great! Will there be a way to restrict packages so that they can only be published through OIDC? That way, even if a maintainer's npm token is compromised, an attacker won't be able to publish unauthorized package versions without write access to the repo

[leobalter]

Trusted publishing with OIDC is now generally available!

Huge thanks to all those who participated in the private preview and provided feedback, that helped us a lot verifying usage and working on small fixes and improvements before the public release!

[twesterhuys]

🎉 congrats on shipping this. With yesterdays announcement¹ of de-facto soon^TM requiring trusted publishing in an automated publishing workflow: is there any plan to support GHES with self-hosted runners or what are the options for publishing workflows depending on those besides manually creating a token and updating a secret every week?

Footnotes

1. https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/#h-npm-s-roadmap-for-hardening-package-publication ↩

[jwagantall]

@leobalter , is there an update on support for self-hosted runners? or separate thread I can follow to get more updates?

[leobalter]

Self hosted runners are supported today if you use Actions in GitHub.com

We have plans to expand support for more providers soon. Work is already in progress.

[mrgrain]

Nice one! Would love to get OIDC support for npm dist-tag or alternatively support for multiple --tag with npm publish.

Many packages maintain multiple tags for a release. To support this, I now still need to use an API token and they can't be scoped to dist-tag only.

[runspired]

Came here to say this. The new restrictions prevent use of a token from CI except also because of this force you to use a token for CI ...

[tuncaulubilge]

Are there any updates around dist-tag support? We migrated to use OIDC for our publishing flows, but that has affected dist-tag automation

[shichengripple001]

any update? btw granular token is not granular at all.

[Sleeckx]

+1 for visibility. Until we have a scope for tag-only, we still need read/write, which defeats the purpose of OIDC. Or am I missing something?

[Nishikant4246]

Use Casee: I publish a mix of open-source and private npm packages, and managing long-lived tokens in CI/CD can be risky and tedious. OIDC’s short lived, tokenless approach would be a huge security and convenience boost for my workflows.
Platform: GitHub Actions.
Publishing Frequency: Around 5–8 packages, updated 2–3 times per month.
Really looking forward to trying this out in the private preview and sharing feedback!!

[voxpelli]

To make this really great I think there are some extra developments needed:

From the npm side:

• Make it possible to disallow everything but trusted publishing for a module
• Possibly require Environment name for Trusted Publishing or at least making it much more clear that Environments are needed for proper security (and suggesting deployment reviewers to be added)

From the GitHub / publishing side:

• Make it possible to require user verification when reviewing a deployment review (session should not be enough, an active 2FA question should be made)
• Make it possible to require more than one review for deployment reviews
• Work with the attestation to include data about reviewers, improving auditability
• Work on improving the preservation of records that attestation statements links to

For both:

• Make it harder to change the related settings and/or 2FA – eg. enforce quarantine on for users on change or require confirmation by other co-maintainer
  • Else the disallow everything but trusted publishing for a module could easily be changed
  • Else deployment review could be easily changed

[dominikg]

at least making it much more clear that Environments are needed for proper security (and suggesting deployment reviewers to be added)

can you elaborate what environments add apart from the ability to have a separate review step (which depending on the setup could be triggered by the same person so merely friction)?

+100 to everything in regards to 2FA handling on gh and npm.

I'd like to add

• make npm publish with 2FA possible from gh workflows

[tom-sherman]

Environments allow you to restrict publish access to specific jobs inside specific workflows.

[ljharb]

… which are editable with write access, or by hijacking an account that's a code owner.

None of these things are silver bullets, and at some point, tiny incomplete improvements create a false sense of security, which is more harmful than not having them at all.

[voxpelli]

Environments allow you to restrict publish access to specific jobs inside specific workflows.

And maybe most importantly: To certain branches.

And since one can limit who can push to eg protected branches that means that one has some extra hurdles to jump through.

Else any branch, even eg RenovateBot branches, could gain access to publish

[voxpelli]

Also discussed here: https://github.com/orgs/community/discussions/174507#discussioncomment-14559845

[ayuhito]

Just crossposting my chat with FE from NPM support who also took note of my roadblocks internally (thank you!).

---

I maintain Fontsource that publishes over the @fontsource and @fontsource-variable scopes (around 2500+ packages). I've been wanting to switch over to OIDC publishing and escape long lived tokens, but there are some major roadblocks that make it infeasible.

• This feature needs to be enabled individually per package via dashboard and is not scriptable. This is infeasible due to the number of packages we host.

  • Possible Solution: A scope-level policy to enable OIDC over all current packages.

• Fontsource automatically publishes new packages by itself. Ideally, I'd never want to let an untrusted source publish on this scope ever again.

  • Possible Solution: Auto-enabling OIDC on all new packages created under a scope. Bonus points if we can only allow packages with provenance to ever be published on said scope.

Another nice to have thing which could also harden non-OIDC environments is the ability to programmatically generate short-lived publish tokens that can then be discarded at the end of a CI run. This at least protects us from CI exfiltration attacks if we properly setup token rotation 🙏

[jakebailey]

Everything mentioned here applies to DefinitelyTyped as well, except we have 9000+ packages and multiple new packages every week.

[ayuhito]

@jakebailey, other than manual token rotation, has DefinitelyTyped found a way around this yet?

[jakebailey]

Nope!

[postspectacular]

Yes to all of these suggestions. This current approach is simply unfeasible for any maintainer who's responsible for dozens (if not hundreds/thousands) of packages. In my case I've got 200+ (correlated) packages. Because of the arbitrary low 50 packages per token limit (in addition to short time limits) of the new granular tokens, Trusted Publishing was the only other option, but this is equally infeasible... Please re-think this all!

[jwndlng]

API support to configure OIDC would really help a lot of organizations to streamline this effort! +1

[ai]

As a maintainer of popular project (postcss) I have doubt about OIDC Trusted Publisher.

For me (I use 2FA to publish with hardware key like YubiKey) adding Trusted Publisher via CI increase risks. Any malware from postcss’s node_modules can make commit & tag and push it to GitHub. Especially it is critical after virus-like malware like tinycolor case when one malware infect other packages. With hardware key I don’t have such risk.

For instance, can we add a rule to GitHub to allow creating tag only if they were signed by some GPG key (which I will store on hardware key)?

(Sorry, if it is a wrong place)

[voxpelli]

OIDC isn’t a quick fix, it simply delegates authorization to another platform – unless one configures that platform to be more secure it will not be more secure.

As I eg mentioned in my commented https://github.com/orgs/community/discussions/161015#discussioncomment-14419367:

1. One should require a specific deploy environment in the OIDC config in npm
2. One should limit that deploy environment to the main branch in GitHub
3. One should add a requirement for reviews to that deploy environment in GitHub (this stops mere pushes from publishing)
4. One should add branch protection rules in GitHub that limits what actions can be done to the main branch

There still are things that should be done by GitHub to improve things (eg require 2FA when reviewing a deployment in GitHub and make it possible to require more than one review and to make it harder to change those settings so that a single compromised account will have a harder time reverting changes) but with that baseline it gets pretty far

[dominikg]

it is not a quick fix for everyone and not perfect, but compared to workflows using long lived automation tokens and no environment restrictions it is an immediate upgrade. gh search for workflows like that

one of the recent attacks succeeded because they were able to exfiltrate such a token.

[kategengler]

I am working to make use of OIDC for emberjs. I echo some of the requests above (enabling for an entire scope, especially).

I also very much would like to be able to have multiple workflows files authorized to publish. We currently publish on tags but also have an automated weekly alpha. Having to merge these workflows makes them both less easy to maintain.

[mannycarrera4]

Just following up here if the solution was to merge the workflows? We currently have different workflows and it fails

[ghiscoding]

Does anyone else have 404 error when trying to publish with OIDC Trusted Publishing? I'm pretty sure that I configured my Trusted Publisher for GitHub properly, I don't think there's any typo in my package name either and NPM publish works fine... it's kind of frustrating because I can't find what the problem is and the 404 error isn't helpful at all. Side note, I use OTP but even if I disable it, that doesn't seem to make a difference. Do we need to change anything in NPM or GitHub settings to get started?

npm notice Publishing to https://registry.npmjs.org/ with tag latest and public access
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/pkg1 - Not found

EDIT

All resolved thanks for Shegox for helping below, the OIDC form is super confusing, they should seriously improve their documentations. Most of the time that a user gets a 404, it's because of that confusing Trusted Publisher NPM form

[ghiscoding]

OMG thanks a ton for all the troubleshooting and providing this fork, it's super helpful. I am indeed in transition to add this feature into Lerna-Lite (which I maintain) and used the pkg-pr-new to test it out and I also copied the code from James (who got it working in Lerna@9) to test it out from his working Lerna OIDC (https://github.com/JamesHenry/lerna-v9-oidc-publishing-example) and I probably missed and screwed that part of which Lerna/Lerna-Lite tool I was really using.

Executing the correct CLI using ./node_modules/@lerna-lite/cli/dist/cli.js publish minor --force-publish -y --push=false --gitTagVersion=false rather than lerna publish minor --force-publish -y --push=false --gitTagVersion=false in the release.yml workflow causes it to publish successfully using OIDC.

Indeed that was it, I changed it as you said and it does work. I feel a little ashamed of this oversight 😶‍🌫️ ... nonetheless, this was super helpful and we'll now have yet another tool, later today, that can fully publish with OIDC. Thanks a ton

It does work with npx lerna (or pnpm exec lerna) which is what people should really be using

[Shegox]

Glad I could help pin down the problem 🚀
And really nice to see the oidc publishing being adopted in lerna-lite (and lerna) 🎉

[aviadhahami]

For anyone else who is getting 404 but are not using lerna -> upgrading the setup-node to use node 24 solved the 404 issue for me (observed w/ node 22)

[ghiscoding]

if you had to upgrade to Node 24 in CI, then I'm assuming that you might have forgot to update your npm version when using older Node, because when you use Node 24 in setup-node, then you are using an npm version that does include OIDC, if however you use an older Node versions then you really need to make sure to run this code npm install -g npm@latest to get OIDC support

[hannoeru]

I'm facing the same issue when using pull_request_target event with npm trust publisher, can the trigger event to push or tag fixed this, is there any docs shows which event is supported by npm trust publisher?

[ObserverOfTime]

When will reusable workflows be supported?

[voxpelli]

They are supported? I use https://github.com/voxpelli/ghatemplates/blob/main/.github/workflows/release-please-oidc.yml in the repos I use OIDC-publishing

[ObserverOfTime]

Oh, I assumed they weren't since I couldn't find any mention and I know they aren't supported in PyPI.

[postspectacular]

So these NPM authentication and token changes mean our only publishing workflow options henceforth are either switching to OICD Trusted Publishing via GHA or using granular access tokens. The problem with the former is that I wanted to migrate my projects to Codeberg soon (which isn't supported). The problem with the latter is that granular tokens are unsuitable for publishing packages from a large Google-style monorepo, since these tokens are limited to 50 packages only (in addition to time limits).

My thi.ng/umbrella repo contains 210 packages. In order to publish them (sometimes all of them will need to be updated), I'd have to first generate multiple granular tokens and then also keep track how many times each token has been used. This adds a lot of extra work and complexity to my monorepo publishing tool. I understand the need for improved NPM security, but as so often, these changes are just poorly thought through (IMO) and continuously add new workloads and complexity on already stretched maintainers...

[christianemanuelson]

It's actually Each token can access up to 50 organizations, and up to either 50 packages, 50 scopes, or a combination of 50 packages and scopes. If that helps.
https://docs.npmjs.com/about-access-tokens#about-granular-access-tokens

[postspectacular]

@christianemanuelson I read that, but how does that help my situation with publishing 200+ packages under a single scope?

[christianemanuelson]

I would think that if a token is configured for a scope that it would include all packages under that scope, but I could be wrong. Either way 2FA per publish is coming so that's only a temporary solution

[christianemanuelson]

I just POC'd it, this token allows me to publish any package under that scope. Not sure why you need to keep track of how many times a granular token, you can use it unlimited times before expiry. The real issue is that [according to their original post](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/#h-npm-s-roadmap-for-hardening-package-publication) required 2FA is coming for local publishing. This will make it effectively impossible to automate. There is an option after first publish to "Do not challenge" your ip for 5 mins, but I don't see any documentation on this option in npm docs and I am not sure this will stay an option.

[postspectacular]

In the meantime I also did some more experimenting and found that granular tokens work for my use case. But the wording about the 50 package limit on the NPM auth token docs is VERY confusing: "Each token can access up to 50 organizations, and up to either 50 packages, 50 scopes, or a combination of 50 packages and scopes." As written (and with no further details given), this reads like these limits are omnipresent for each token, but in fact one can also create tokens which can access ALL packages under your control (However this is not stated in this article). The 50 limit only seems to apply when creating a token which is only allowed to access a subset...

[jwndlng]

We, same as here, have repositories that have multiple workflow files to publish packages. The current settings do only allow 1 filename.

@leobalter Would it be an option to make either the file name or the environments mandatory, instead of having only the file name mandatory?

[bruce-y]

Seconded on this, while we would love to start using the trusted publisher config, our build pipelines are split into two separate workflows for individual environments that would both need to publish the same package to NPM (beta vs latest). This seems like it would easily break many setups if we are forced to only specify a single file name to be trusted.

[postspectacular]

How is this workflow supposed to work for new packages, if one has to first to manually create a "Trusted Publisher" config via package settings on npmjs.com, which will obviously only not work for entirely new packages? This all feels not very well thought through, or rather only seems to have considered some very basic use cases and not collected feedback from maintainers of larger projects. The entire approach is hostile to all maintainers responsible for dozens/hundreds/thousands of packages (same goes for the arbitrarily chosen useless 50 packages-per-token-limit of granular tokens). If there's some feasible solution for publishing larger numbers of packages, at the very least please update the relevant docs...

[ghiscoding]

there's also an NPM CLI issue for this: npm/cli#8544
I'm not sure if they look at the number of votes to work on these things but it's probably a good idea to upvote it anyway

[tkumark]

Any updates on when npm OICD will be available for Bitbucket pipelines?

[leobalter]

We have work in progress for a feature you could virtually add custom origins as long as they provide a proper Open ID Connect validation. We don't have a date yet but I'd expect it early 2026.