OIDC Trusted Publishing

How OIDC Trusted Publishing Works

OIDC trusted publishing replaces a long-lived package token with a short-lived, federated assertion from the CI system. That assertion is used to prove the workflow is current and authorised for a publish action, so the registry can grant a narrowly scoped, ephemeral publishing session instead of trusting a static secret.

This model shifts trust from stored credentials to runtime evidence. The registry is not asking, “does this pipeline know a durable token?”, but “is this build invocation the expected one, from the expected system, at the expected moment?” That makes the security boundary closer to the build event and reduces the value of token theft.

Why It Matters for Package Integrity

Trusted publishing is valuable because package registries are high-value targets for supply chain abuse. If an attacker can steal or reuse a durable publishing token, they may ship malicious versions, hijack maintainer publishing rights, or keep publishing after an incident has been contained. A short-lived federated proof narrows that window and removes one of the most attractive standing credentials in the path.

It also helps with operational hygiene. Teams no longer need to distribute, rotate, and protect a static publish token across CI jobs, developer machines, or automation paths. That reduces secret sprawl and lowers the chance that a forgotten credential survives long after the workflow or maintainer context has changed.

What Makes It Different from Traditional Token-Based Publishing

The key difference is that OIDC trusted publishing binds access to identity and context rather than to possession of a reusable secret. A durable token can be copied, cached, logged, exfiltrated, or accidentally reused. A federated assertion is time-bound and workflow-bound, so compromise tends to be narrower and less persistent.

That does not make publishing invulnerable. The security now depends on the integrity of the CI trust chain, the correctness of the federation policy, and the registry’s checks on claims such as repository, workflow, audience, and issuer. If those checks are too broad, an attacker may still abuse a legitimate pipeline or impersonate an approved publishing context.

Where Practitioners Apply It

OIDC trusted publishing is most relevant for package ecosystems and release pipelines that currently depend on manually managed publish secrets. It is commonly adopted where builds are already automated, releases are repeatable, and the goal is to make publishing less dependent on human-held credentials.

It also sits naturally alongside broader identity and federation controls. The same design logic appears in modern CI/CD security guidance, where least privilege, workload federation, and ephemeral credentials are preferred over standing secrets. For teams building or reviewing that model, NHIMG’s CI/CD Pipeline Identity Security Guide is a useful companion, and the OpenID Connect Core 1.0 specification defines the identity layer that makes the federation model work.

Risk and Threat Considerations

Trusted publishing reduces secret exposure, but it also concentrates trust in the CI environment and in the federation policy itself. If an attacker can tamper with the workflow, abuse repository permissions, or compromise the build runner, they may still obtain legitimate publish access without ever stealing a static token.

Failure mechanism: Weak claim validation, overbroad workflow trust, or compromised CI state can let a malicious run present itself as an authorised publisher and receive ephemeral access.

Impact: The result can be unauthorised package publication, malicious version release, or post-incident republishing even though durable secrets were removed.

Practitioner Guidance

Why practitioners should care: Trusted publishing is only as strong as the claims it trusts. Treat the CI-to-registry exchange as an access decision, not just a convenience feature, and verify that the workflow identity, repository context, and trigger conditions are all tightly constrained.

What to watch for: Review whether your release path still allows fallback tokens, overly broad federated trust, or human bypasses that undermine the point of ephemeral publishing. The control objective is not simply “use OIDC”, but “make static publish credentials unnecessary wherever possible.”

Related resources from NHI Mgmt Group

• Guide: Identity Provider and SSO Security Guide
• Should teams prioritize OIDC trusted publishing over token rotation for npm releases?
• What breaks when a long-lived npm token is left active after adopting OIDC publishing?
• What do security teams get wrong about package provenance and trusted publishing?
• Who is accountable when a release workflow publishes malicious code through trusted publishing?