OIDC Trusted Publishing

Expanded Definition

OIDC trusted publishing is a federated publishing pattern in which a CI workflow presents a signed OpenID Connect assertion to a registry or package service, proving the job is current, approved, and running in the expected automation context. The registry then issues short-lived publish permission instead of relying on a stored package token. In NHI terms, the workflow becomes a transient publishing identity with narrowly scoped authority, which reduces the durability of secrets and the blast radius of compromise.

Definitions vary across vendors on how much trust should be placed in workflow metadata, branch protections, runner provenance, and environment claims. That means implementation quality depends on strict claim validation, audience binding, and policy controls at the receiving service, not merely on “using OIDC.” For governance context, NIST Cybersecurity Framework 2.0 frames this as an access and assurance problem, while NHI management treats it as a secret-elimination and lifecycle-control pattern. The most common misapplication is replacing a long-lived token with OIDC while failing to restrict the trusted claims, which occurs when any workflow in the repository can still obtain publish access.

Examples and Use Cases

Implementing OIDC trusted publishing rigorously often introduces policy complexity, requiring organisations to weigh secret removal and faster rotation against stricter workflow controls and registry-side validation.

• A package build in GitHub Actions exchanges an OIDC assertion for ephemeral release access, eliminating a stored publish token on the runner.
• A hardened CI pipeline allows publishing only from a protected branch and only when the workflow identity matches the expected repository and environment claims.
• A software vendor moves from static registry credentials to federation after reviewing the attack path described in OneLogin API Key Vulnerability, which shows how durable secrets can be abused once exposed.
• An open-source maintainer uses federated publishing to reduce secret sprawl and align release automation with the least-privilege guidance in NIST Cybersecurity Framework 2.0.
• A compliance team requires every publishing workflow to be traceable to a specific repository, ref, and job so that provenance can be audited after release.

Why It Matters in NHI Security

OIDC trusted publishing matters because it removes a high-value class of standing secrets from CI/CD, but only if the federation policy is strict enough to prevent unauthorized workflows from minting publish access. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes durable package tokens a predictable exposure point. In that environment, trusted publishing is not just a convenience feature; it is a direct control for reducing secret persistence, revocation burden, and supply-chain blast radius. It also supports Zero Trust principles by making each publish action depend on current context rather than on a reusable credential. For operational teams, the term becomes relevant when release automation is reviewed after a leak, a suspicious package upload, or a CI compromise, because the old token-based model is then clearly the weak link.

For broader identity governance, the pattern aligns with the NHI lifecycle concerns described in Ultimate Guide to NHIs, and the same trust-boundary logic should be evaluated alongside NIST Cybersecurity Framework 2.0 when organisations define access review, monitoring, and incident response expectations.

Related resources from NHI Mgmt Group

• 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?
• Trusted Publishing
• What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?