NPM Tokens Revoked: Migrate To Trusted Publishing

Oct 19, 2025 by ADMIN 50 views

NPM is Revoking Classic Tokens: What You Need to Know

Hey guys! Heads up, because some important changes are coming to how you handle your npm packages. This is all about making things more secure for everyone. Let's dive into what's happening and what you need to do, especially if you're an ioBroker adapter developer.

What's the Deal with NPM and Tokens?

So, npm (that's the Node Package Manager, for those new to the game) is tightening up its security. They're phasing out "classic tokens," which are basically the old-school way of giving you access to publish and manage your packages. The big news? Early November 2025, those classic tokens are going poof! This is part of a larger effort to protect the npm ecosystem from supply chain attacks, which, in a nutshell, are when bad actors try to sneak malicious code into your projects through compromised tokens.

The Email You Might Have Seen

You might have already seen an email from npm detailing these changes. Here’s a quick recap of the important bits:

Phase 1:
- October 13th: New, limited-time (90-day max, 7-day default) granular tokens. Also, TOTP 2FA configurations are disabled, but existing ones still work.
- Early November 2025: All classic tokens will be revoked.
What You Need to Do: If you use classic tokens in any automation, like in CI/CD pipelines (that’s Continuous Integration/Continuous Deployment, the automated build and release stuff) or local development, you must migrate to granular access tokens or, even better, to Trusted Publishing before early November 2025 to avoid any publishing issues.
More Changes Coming: This is just the beginning. Expect more security updates in the coming months, including improvements to 2FA and expanded support for trusted publishers.
Why the Change: Compromised long-lived tokens are a major security risk. These changes are crucial for protecting the npm ecosystem and your packages.

What Does This Mean for You?

If you're an ioBroker adapter developer (or any npm package maintainer, really), this means you need to take action. The old way of doing things with those classic tokens will no longer work. That means your automated publishing processes, the ones that build and release your adapter updates, will break. But don't worry, there's a solution: Trusted Publishing.

Migration to Trusted Publishing: The Recommended Route

The key takeaway here is: migrate to Trusted Publishing before Early November 2025! This is the official recommendation from npm, and it’s the best way to keep your publishing workflows humming along smoothly. The good news? The ioBroker tools are already set up to handle this!

Why Trusted Publishing?

Trusted Publishing is a more secure way to handle your publishing process. It uses a system called OpenID Connect (OIDC) to verify your identity and grant access to publish your packages. It's much safer than relying on long-lived tokens that could be compromised.

How to Migrate to Trusted Publishing

So, how do you get this set up? Here's the lowdown on the steps you need to take.

Setting Up the Trust Relationship

First things first, you need to configure Trusted Publishing in your npm account. Here's how:

Log in to npmjs.com: Make sure you're using an account that has permission to publish your package.
Go to your package page:
- Go to https://www.npmjs.com/package/YOUR-PACKAGE-NAME (replace YOUR-PACKAGE-NAME with your actual package name).
- Click on the "Settings" tab.
Configure Trusted Publishing:
- Scroll down to the "Publishing access" section.
- Click on "Automate publishing with GitHub Actions" or "Add trusted publisher." (Choose the GitHub Actions option if you use GitHub Actions for your release workflow, which is the standard for ioBroker adapters.)
- Fill in the required info:
  - Repository owner: Your GitHub username or organization (e.g., ioBroker if you're an ioBroker adapter).
  - Repository name: The name of your adapter repository (e.g., ioBroker.your-adapter).
  - Workflow name: test-and-release.yml (or the name of your release workflow file). This is usually the default file name, but make sure it matches your setup.
  - Environment: Leave this blank.
Save the configuration. That's it! You've set up the trust relationship.

For more detailed info, check out:

Adapting Your `test-and-release.yml` Workflow

Now, let's talk about the test-and-release.yml file. This is the file that controls your automated release process. You'll need to make a few changes here if you're using the standard workflow (and if you're not, you really should consider switching!).

Open test-and-release.yml: Edit this file directly on GitHub or in your development environment.

Remove the npm-token: Find the deploy job in your test-and-release.yml file. It should look something like this:

# Deploys the final package to NPM
deploy:
  needs: [check-and-lint, adapter-tests]

  # Trigger this step only when a commit on any branch is tagged with a version number
  if: |
    contains(github.event.head_commit.message, '[skip ci]') == false &&
    github.event_name == 'push' &&
    startsWith(github.ref, 'refs/tags/v')

  runs-on: ubuntu-latest

  # Write permissions are required to create Github releases
  permissions:
    contents: write

  steps:
    - uses: ioBroker/testing-action-deploy@v1
      with:
        node-version: '20.x'
        # Uncomment the following line if your adapter cannot be installed using 'npm ci'
        # install-command: 'npm install'
        build: true
        npm-token: ${{ secrets.NPM_TOKEN }}
        github-token: ${{ secrets.GITHUB_TOKEN }}

Find the line that starts with npm-token:. Remove this line (or comment it out by adding a # at the beginning).
Locate the permissions: block. If it's not there, add it. Make sure it includes contents: write (as shown in the example).
Add a line id-token: write to the permissions block. Be careful with the indentation!

Test the Workflow: Create a test release to make sure everything works.
Remove the NPM_TOKEN Secret: After confirming everything's working, you can remove the NPM_TOKEN secret from your GitHub repository settings. (This is optional, but it's good practice to clean up unused secrets.)

If You're Using a Custom Workflow

If you're not using the standard test-and-release.yml workflow, things are a little more involved. Here’s what you should do:

Consider Switching to the Standard Workflow: Seriously, consider it. It's the easiest and most supported approach.
If You Must Keep Your Custom Workflow: At the very least, use the ioBroker/testing-action-deploy@v1 action within your workflow. This will make the migration easier.
If You're REALLY Stuck with a Custom Deploy Mechanism:
- Follow the instructions in the NPM Trusted Publishing documentation.
- Make sure you entered the correct workflow name when setting up "Trusted Publishing."
- Use the newest npm release in your workflow. You might need to use a dedicated npm install -g npm@latest command to update npm, especially if the npm version in your Node release is outdated. Put the npm upgrade near the deploy command, but don't update npm for the entire workflow – this could cause problems.
- Do NOT use a token or try to log in to npm in your workflow. Instead, use npm publish without any authorization.

Coming Soon: Automated PRs!

The ioBroker team is also working on a tool that will generate a Pull Request (PR) to automatically add these changes to the standard test-and-release.yml workflow. So, keep an eye out for that! Note that you will not receive a PR if you are not using the default / standard workflow.

Need Help?

If you have any questions or run into any issues, don't hesitate to reach out! The best places to get help are our development channels on Telegram or GitHub (invites are available on https://www.iobroker.dev), or just drop a comment mentioning me (@mcm1957).

A HUGE THANKS to all of you for maintaining these amazing adapters! Let's work together to make sure everyone has the best user experience possible.

Your friendly ioBroker Check and Service Bot