ensure support for OIDC with the official registry

[travi]

context https://github.com/orgs/community/discussions/161015

[travi]

first successful publish with OIDC: https://github.com/travi-test/npm-oidc-test/releases/tag/v0.1.0 🎉

spent most of the effort getting it to actually use https://github.com/semantic-release/npm/releases/tag/v13.0.0-alpha.5, but it worked smoothly once i sorted through that

important: this has all logic commented out for setting the token in the npmrc from the expected environment variable and verifying with npm whoami, so deciding how to handle those steps conditionally still needs to be figured out

[travi]

in theory, we should be able to try a publish with the dry-run flag to verify the auth context. assuming this doesnt have some hidden problem, i would expect that to give us better feedback than whoami that we are using today. it may even be more universal across alternative registries too

[travi]

we'll need to confirm similar details with this compared to issues we ran into with the original rollout of automation tokens: #277

[travi]

we should be able to try a publish with the dry-run flag to verify the auth context

i've been testing this out some today. here are my findings that i think are going to be important for us:

• "npm warn This command requires you to be logged in to https://registry.npmjs.org/ (dry-run)" is included in the output when OIDC token exchange fails and when no npm token is provided
• even when the warning is provided, the publish command (with dry-run flag) exits with a zero exit-code, so we wouldnt be able to rely on exit code of running this command to determine if a proper auth context exists or not
• i dont think there is any flag to convince npm to exit non-zero for warnings like that one
• in the absence of being able to use the exit code, we would have to parse the output and look for that warning line. i'm hesitant to do that with a very strict match in case the message would change in the future. maybe we could just fail in all cases that a warning was printed while running that command
• if running the publish command with npm v11 and a version with a dash in it, like 0.0.0-semantically-released (this step would be before we set the version during the release, so this would use the version from package.json), npm will fail the publish highlighting that a dist-tag is required when publishing a pre-release. i think this is good feedback to provide, but this is new behavior that didnt exist in v10. i'm glad i specifically hit this situation with v11 as this could have easily caused us to release a buggy first implementation. since this is being done as a dry-run, we can just define any tag and do it always without worrying about it pushing anything real to the registry

i think we're likely headed toward running something very close to npm publish --dry-run --tag=semantic-release-auth-check and needing to parse that output to look for npm warn in the output, hopefully without ANSI color codes making that more difficult.

[travi]

we'll need to confirm similar details with this compared to issues we ran into with the original rollout of automation tokens: #277

in addition to the whoami check from #277, we also need to handle adding a dist tag, which also caused issues with automation tokens: #298.

[hashtagchris]

"npm warn This command requires you to be logged in to https://registry.npmjs.org/ (dry-run)" is included in the output when OIDC token exchange fails and when no npm token is provided

👋🏼 I work on the npm registry part-time. If you prefer not to parse cli dry-run logs to determine if OIDC will be used to publish, there's the option to make a https request to npm's public OIDC token exchange API and get back a short-lived npm registry token for publishing. The token exchange API is described briefly in this PR: npm/cli#8336. Depending on the number of CI systems you support, this might be straightforward..

Option 1: Retrieve and use a short-lived token

You could retrieve a short-lived token beforehand, and then later use it for publishing only. In the context of a GitHub Actions workflow:

  - run: npm config set //registry.npmjs.org/:_authToken "$SHORT_LIVED_NPM_TOKEN"
    if: ${{ env.SHORT_LIVED_NPM_TOKEN }
    
  - run: npm publish

Or if you're using actions/setup-node:

  - run: npm publish
    env:
       NODE_AUTH_TOKEN=${{ env.SHORT_LIVED_NPM_TOKEN || secrets.NPM_AUTOMATION_TOKEN }}

Option 2: Retrieve and discard a short-lived token

Or you could retrieve a short-lived token beforehand and discard it, just to verify OIDC publish is configured for the given package and CI context (e.g. GitHub repo or GitLab project).

Assuming the npm cli is being used to publish, I would only use this technique if you know the npm cli version is new enough to include the OIDC publish feature (npm/cli#8336). Option 1 should work for older versions of the npm cli, and other npm package managers.

---

Update, August 2025: The token exchange API is now documented at https://api-docs.npmjs.com as well.