🚀 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. 🙏

[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 ↩

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

[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

[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 🙏

[pngwn]

hi! I don't have 2500 only 68 but, i also didn't want to do it manually.

I agree that either an API or scope level trusted publishing would be great.

But I didn't want to wait so I did it with playwright: https://gist.github.com/pngwn/e7b844dfc6fa2dda82b74a695c05059b

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

[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

[Shegox]

Your repository is private, so I can't see it. Can you make it public or alternatively share at least the workflowfile and the full output of a failed workflow run.

Can you share additionally the exact configuration of the OIDC config within NPM (e.g. via a screenshot). This is as well not publicly visible for non-package maintainers.

[ghiscoding]

oh gosh I'm not sure how it got private, that was a mistake, it's public now. I tried running the release again and same 404. There's a screenshot of the trusted publisher setting in the repo

I added some more logs and it seems to be escaping the last slash at some point in the execution but I don't know why. Is it supposed to be escaped? The link is working so it might be ok

HttpErrorGeneral: 404 Not Found - PUT https://registry.npmjs.org/@lerna-lite-test%2foidc - Not found

[Shegox]

I found the problem. It seems that your workflow executes lerna (version 8.2.4 (normal lerna only supports oidc publishing >=9.0.0)) rather then your own lerna-lite (which I assume you wanted to use). A hint for this is the used version number here: https://github.com/lerna-lite-test/oidc/actions/runs/18010205815/job/51240536104#step:8:22

Thu, 25 Sep 2025 14:08:34 GMT lerna sill argv }
Thu, 25 Sep 2025 14:08:34 GMT lerna notice cli v8.2.4
Thu, 25 Sep 2025 14:08:34 GMT lerna verb packageConfigs Resolving packages based on package.json "workspaces" configuration.

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.

My test repository/workflow run: https://github.com/Shegox/oidc/actions/runs/18011383024/job/51244726227#step:8:79
The relevant change : lerna-lite-test/oidc@main...Shegox:oidc:main#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34L104
My demo package published using OIDC: https://www.npmjs.com/package/@shegox-test-org/npm-demo-test/v/0.1.0

[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 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) 🎉