Is anyone working on OIDC identity tokens for pipelines? (needed for npm trusted publishing)

[datalackey]

Hi, I run releases for a small open-source project (@doikayt/typescript-build-config) from a Woodpecker pipeline on ci.codeberg.org, publishing to npm.

Why I'm asking now. npm is removing direct publishing with granular access tokens in January 2027 (docs). The replacement for CI is trusted publishing, which is OIDC-based. It currently supports GitHub Actions, GitLab CI/CD and CircleCI on hosted runners, and lists self-hosted runners as planned (docs). Woodpecker pipelines can't take part today because they don't receive an OIDC identity token.

What I found.

• Add and expose job/trigger context as a JWT #1126 ("Add and expose job/trigger context as a JWT") asked for this in 2022. The last reply in 2023 said there is no ETA, and it was converted to a discussion.
• Workload identities for pipelines #4837 ("Workload identities for pipelines") was closed as a duplicate of Add and expose job/trigger context as a JWT #1126 and Inject bot / api token as environment variable #368 in 2025.
• Inject bot / api token as environment variable #368 is still open, but it was last touched in 2022.
• I couldn't find OIDC, JWT or identity tokens mentioned in the docs on environment variables, workflow syntax or secrets.

Questions.

1. Is anyone working on, or planning, OIDC identity tokens for pipelines? If not, would a design discussion be welcome? I'd be happy to help test, though I can't promise code.
2. If this were built, would the tokens' issuer and discovery endpoint be run per Woodpecker server? A registry such as npm would need to trust each server's issuer, so I'm curious how that is expected to work for a shared instance like ci.codeberg.org.
3. Is there a recommended workaround in the meantime for publishing to npm without a long-lived token?

Thanks for the work on Woodpecker.

[fatihdogann]

Small but important clarification from the npm side: even once Woodpecker can issue OIDC tokens, npm trusted publishing would not accept them today.

npm does not do generic OIDC discovery. It has a fixed set of provider integrations, and the "Trusted Publisher" form on npmjs.com only offers GitHub Actions, GitLab CI/CD and CircleCI. Each one is configured with provider-specific identifiers — GitHub Actions wants org/user + repository + workflow filename, GitLab wants namespace + project + top-level CI file path, CircleCI wants org/project/pipeline IDs — and npm validates the incoming token's claims against that record. There is no field for an arbitrary issuer or discovery URL, so a per-server issuer such as ci.codeberg.org would still have nothing to be registered against.

That answers question 2 as well: the mapping is not "server → issuer", it is "provider → npm integration". Self-hosted runners are explicitly not supported yet (listed as planned), which covers Woodpecker's shape too.

References: https://docs.npmjs.com/trusted-publishers (see "Supported CI/CD providers" and "Configuring trusted publishing"), and the underlying token exchange API: https://api-docs.npmjs.com/#tag/registry.npmjs.org/operation/exchangeOidcToken

Two things worth separating:

1. Woodpecker's OIDC tokens are still useful for registries and systems that accept arbitrary issuers, so the feature request stands on its own. It is just not sufficient for npm by itself — npm would also have to add Woodpecker as a provider.

2. In the meantime, the least-bad workaround for npm specifically is to run the publish step somewhere npm already trusts. A common shape: keep build and tagging in Woodpecker, and let a GitHub Actions workflow in a mirror or upstream repo run npm publish (or npm stage publish) on tag, with permissions: id-token: write. Two details matter: the version floors are npm CLI ≥ 11.5.1 and Node ≥ 22.14.0, and the package's repository.url in package.json must exactly match the GitHub repository that publishes.

Granular access tokens still work today, but npm is restricting tokens that bypass 2FA for account changes and direct publishing, so that is a stopgap rather than a destination. Staged publishing is not an escape hatch either: npm stage publish is itself gated behind a trusted publisher.

Whether a design discussion would be welcome is for the maintainers to say, but the constraint above is worth having before designing the token format: for npm, the issuer has to be a provider npm already trusts.

[6543]

we als have the same issue: https://codeberg.org/woodpecker-plugins/ts-plugin/issues/179#issuecomment-25283653

... this just limits access to automation to big company's :/

In terms of adding this feature, npm would likely not enable it for any selfhosted instance as anybody can just fork and modify woodpecker to make it always report what the hoster wants ... codeberg is the only one that could perhaps get this accepted.

[6543]

also generic discussion about this one can find at #2285