Catch up on the new NPM Trusted Publishing feature
NPM Trusted Publishing replaces risky long-lived tokens with secure OIDC authentication. Learn how this new feature eliminates token exfiltration attacks and makes publishing packages safer with zero token management overhead.
NPM traditionally used token-based authentication to secure access to publishing packages. Developers would generate long-lived access tokens and store them as secrets in their CI/CD pipelines. These tokens would authenticate publish requests, giving the CI system permission to push new versions to the npm registry.
It worked well, until it didn't.
A common NPM attack vector involves exfiltration methods that steal the token. Long-lived tokens can be accidentally exposed in CI logs, configuration files, or version control systems. Once compromised, these tokens provide persistent access until manually revoked, and they often have broader permissions than strictly necessary. Managing token rotation and lifecycle became an ongoing security and operational burden.
NPM Trusted Publishing is a new feature that replaces token-based authentication with a more secure, modern approach. And is a recommended security capability by the OpenSSF Securing Software Repositories Working Group.
It uses OIDC (OpenID Connect) under the hood, the same authentication standard that powers single sign-on across many services you already use. Instead of relying on long-lived secrets, Trusted Publishing establishes a trust relationship between npm and your CI/CD provider. You configure which specific workflow is authorised to publish your package, and npm verifies that authorisation cryptographically during each publish attempt.
The beauty of this approach is its simplicity. When you run npm publish in an authorised workflow, the npm CLI automatically detects the OIDC environment and handles authentication transparently. No manual token management required.
It works by doing the following key interactions: First, you configure a trust policy on npm.com for your package. This policy specifies exactly which CI workflow is allowed to publish, down to the repository name, workflow filename, and optionally even the deployment environment. Think of it as allowlisting a specific publishing pipeline.
When your CI workflow runs, the provider (GitHub Actions or GitLab CI/CD) generates a short-lived OIDC identity token, a cryptographically signed JWT that includes claims about the workflow context. This includes details like the repository, workflow file, commit SHA, and more.
npm
Your workflow sends this OIDC token to npm during the publish operation. NPM then validates the token by checking its signature against the provider's public keys (discovered via OpenID Connect's standard discovery mechanism), verifying that it hasn't expired, and ensuring that all the claims match your pre-configured trust policy.
If everything checks out, npm exchanges this OIDC token for a short-lived npm API token that's used to complete the publish. This token exists only for the duration of that single operation.
It's secure because: Every credential is ephemeral. The OIDC tokens are valid for minutes, not months. Even if somehow intercepted, they can't be reused—they're bound to a specific workflow execution and expire almost immediately.
The tokens are cryptographically signed by your CI provider. NPM verifies these signatures using the provider's public keys, making forgery practically impossible. You can't just create a fake token that looks legitimate.
The authorisation is workflow-specific and non-extractable. Unlike traditional tokens that can be copied, stolen, or accidentally leaked, OIDC tokens are generated on demand by the CI provider itself and never exist outside the secure workflow environment. An attacker would need to compromise your entire repository and CI configuration to abuse this, rather than just stealing a single token value.
Plus, as a bonus, npm automatically generates provenance attestations when you publish via Trusted Publishing. This provides cryptographic proof of where and how your package was built, helping users verify its authenticity.
Why you should adopt it: It's far more secure than token-based authentication. You eliminate the entire class of vulnerabilities associated with long-lived credentials. No more worrying about tokens in logs, no rotation policies to enforce, and no broad permissions to manage.
It's easy to set up and use. Configuration takes just a few minutes on npm.com and a slight adjustment to your workflow file to add OIDC permissions. After that, it just works™.
There's no token handling to worry about. No more storing secrets, no more rotation reminders, no more accidentally committing tokens to version control. The npm CLI handles everything automatically when it detects an OIDC environment.
If you do end up adopting Trusted Publishing, make sure you adjust the existing publication methods to be as secure as your situation allows.
Limitations: Only GitHub Actions and GitLab CI/CD are currently supported, and specifically their cloud-hosted runners (GitHub-hosted and GitLab.com shared runners). Self-hosted runners aren't supported yet, though they're planned for future releases.
Each package can have only one trusted publisher configured at a time. While you can change this configuration whenever needed, you can't have multiple different workflows publishing the same package simultaneously via Trusted Publishing.
Also, Trusted Publishing currently only handles the publish operation itself. If your workflow needs to install private npm dependencies, you'll still need a read-only token for that part, though that's a much smaller security surface than a full publish token.