What is trusted publishing on a package registry, and how does it differ from a long-lived API token?
answer
- the credential is not stored anywhere
- identity proven, not secret kept
- the CI provider signs the claims
- registry trades identity for a scoped token
- short-lived and audience-bound
basics
~20 sTrusted publishing lets a registry accept a release from one specific CI workflow by verifying a short-lived OIDC identity token, instead of a long-lived API token stored as a CI secret. No reusable credential exists to steal.
solid answer
~50 sWith a classic API token, a maintainer generates a secret at the registry, pastes it into CI, and it stays valid until someone revokes it. Anything that can read that secret - a compromised build step, a leaked log, a stale backup of the repo settings - can publish from anywhere, forever. Trusted publishing inverts the setup: the project owner registers, at the registry, which repository and which workflow are allowed to publish. At release time the workflow asks its CI provider for a signed OIDC identity token describing itself, presents it to the registry, and gets back a credential that is short-lived and scoped to that one package. Nothing durable is stored in CI, so there is no secret to leak; and a token that does leak is useless minutes later and useless anywhere but that package.
go deeper
Be ready to state the difference in one breath: a stored secret that lasts until revoked, versus an identity the CI provider proves for each run in exchange for a short-lived, package-scoped token.
Expect to walk the exchange end to end - who registers the publisher, who signs the claims, what the registry checks, and what it hands back - without hand-waving over where the credential comes from.
You should be able to say what this control actually buys and what it leaves open, and to argue for it in terms of blast radius rather than as a best practice with no stated threat.
Own the position that publish credentials are an inventory to shrink. Be able to explain what you do for registries that do not support it, and how you would know the estate is getting better rather than just newer.
## The problem it solves Publishing a package is one of the highest-value actions in a software supply chain: whoever can do it can reach every consumer of that package on their next resolve. For years the standard mechanism was a **registry API token** - a bearer secret generated in a web UI and pasted into CI as an encrypted variable. A bearer secret has three properties that make it a poor fit for that level of power: 1. **It is long-lived.** It works until a human remembers to revoke it. A token pasted in two years ago is still a live publish credential today. 2. **It is portable.** It carries no notion of where it is used. The registry cannot tell a release job from a laptop in another country; both present the same string. 3. **It is copyable.** Every process inside the release job, every third-party step that job invokes, and anything that can print the environment can read it and exfiltrate it. Once copied, the theft is silent - the original keeps working. That is why a single compromised build step in a release job is a full package takeover: it does not need to tamper with the artifact in that run, it just needs to walk away with the token and publish at leisure. ## What trusted publishing does instead Trusted publishing (sometimes called OIDC publishing) replaces the stored secret with a **proof of identity minted fresh for each run**. The shape is always the same, whatever the ecosystem: - **Configuration, once.** A project owner registers a *trusted publisher* against the package at the registry: the CI provider (the OIDC issuer), the repository, the workflow file that is allowed to publish, and often a deployment environment name. This registration is the trust anchor, and only a project owner can create it. - **A token, per run.** During a release run, the job asks its CI provider for an OIDC ID token. The CI provider - not the user - fills in the claims: who the issuer is, which repository this is, which workflow file is executing, which ref or environment. The token is signed by the issuer and carries an audience naming the registry it is meant for, plus a very short expiry. - **An exchange, at the registry.** The workflow posts that token to the registry. The registry validates the signature against the issuer's published keys, checks the audience so a token minted for one registry cannot be replayed at another, and compares the claims against the registered publisher. On a match it returns a **short-lived API token scoped to that one package**, which the normal upload step then uses. So the durable secret disappears. What lives in CI configuration is not a credential at all - it is a statement of identity that only the CI provider can sign. ## What actually changes, in blast-radius terms | Property | Long-lived API token | Trusted publishing | |---|---|---| | Lifetime | until revoked | minutes | | Usable from | anywhere | only inside a matching workflow run | | Scope | often the whole account, all packages | the one package the exchange was for | | Theft detectable | no, copying is silent | replay window is tiny and audience-bound | That middle row is the important one. A stolen bearer token is useful to an attacker on their own machine at a time of their choosing. A minted trusted-publishing credential is only obtainable by *being* the authorised workflow, which means the attack surface moves from *stealing a string* to *getting code to run inside a specific job in a specific repository* - a much noisier and better-defended thing to do. ## What it is not Trusted publishing answers **who is publishing**. It says nothing about **what is inside** the artifact, and nothing about whether the commit that triggered the release deserved to be released. It is an authentication control on the release path, not an integrity control on the contents. A malicious change merged into the release branch publishes through trusted publishing perfectly cleanly. It is also not universally available. It began at one major registry and has spread, but any real organisation publishes to registries and internal repositories that still only accept a token. The honest posture is: use trusted publishing wherever the registry supports it, and treat every remaining long-lived publish token as an item on a list you are trying to shorten - scoped to one package, owned by a named team, and rotated. ## How to talk about it The crisp framing in an interview is: *a long-lived token is a secret you must keep; a trusted-publishing exchange is an identity you must prove.* Secrets leak because they are things; identities are harder to steal because they are properties of where the code is running.
- If nothing is stored in CI, what is the thing an attacker would go after instead?The registration itself and the ability to run as the authorised workflow. That means the registry account that can add or edit a trusted publisher, write access to the branch or tag that triggers the release job, and the workflow file itself. The credential moved out of reach, so the interesting targets became repository permissions and registry ownership.
- Why is the audience claim on the OIDC token worth caring about?It names the intended recipient. Without it, a token minted so a job can prove itself to one service could be replayed by that service, or by anything that captured it, against a different one that trusts the same issuer. Binding the audience to the registry makes the identity token useful for exactly one exchange.
- Does trusted publishing remove the need for multi-factor on maintainer accounts?No. Someone who takes over a project owner account can register a new trusted publisher pointing at a repository they control, or publish manually. Trusted publishing hardens the automated release path; the account that can reconfigure that path is still the root of trust and still needs strong authentication.
A long-lived API token is a copied house key: whoever holds it gets in, forever. Trusted publishing is a doorman who recognises one specific courier and hands over a badge that expires before lunch.
saying these in an interview costs you the question
- Says trusted publishing verifies the package contents
- Thinks the OIDC token itself uploads the artifact
- Calls it just a shorter-lived API token
- Assumes the developer supplies the identity claims
- Believes it removes the need for branch protection