An Azure Pipelines job fails with 401 Unauthorized while restoring from an Azure Artifacts feed in the same organization. How does a pipeline authenticate to a feed, and what would you check?

## Two halves of the problem Every Azure Artifacts 401 in CI is one of two things: the client never received credentials, or it received credentials belonging to an identity that has no role on the feed. Diagnosing quickly means knowing which half you are in. ## The identity A pipeline run does not act as the person who queued it. It acts as a **build service identity**, and which one depends on the job authorization scope: - Scope **project**: `{Project Name} Build Service ({Organization})` - Scope **collection** (organization): `Project Collection Build Service ({Organization})` Azure DevOps mints a short-lived OAuth token for this identity for the duration of the run — the value exposed as `$(System.AccessToken)` when you enable it. That token is what feed access rides on for feeds inside the same organization. There is no need for a personal access token in this path, and hardcoding one in YAML is a straightforward secret-management defect. ## The credential injection The token existing is not enough: `dotnet restore`, `npm ci`, `pip install` and `mvn` each read credentials from their own config file, and none of them know anything about Azure DevOps. That is the job of an authentication task, which writes the run's credentials into the right place before your restore step runs: | Ecosystem | Task | Writes into | |---|---|---| | NuGet / .NET | `NuGetAuthenticate@1` | NuGet credential provider environment | | npm | `npmAuthenticate@0` | the `.npmrc` you name in `workingFile` | | pip | `PipAuthenticate@1` | pip index credentials for the run | | twine (publish) | `TwineAuthenticate@1` | a twine config for the named feed | | Maven | `MavenAuthenticate@0` | `~/.m2/settings.xml` server entries | The classic mistake is adding the authentication task *after* the restore, or in a different job. Credentials are established per job on the agent, so a task in job A does nothing for job B. Another is authenticating npm but pointing `workingFile` at a path where no `.npmrc` exists — the task succeeds, the install still 401s, because the registry line and the credential line have to end up in the same file the client reads. ## The permission If credentials are arriving and the 401 persists, the identity has no useful role on the feed. Feed roles are granted in **Feed settings → Permissions**, and the build service identity is a principal you add there like any user: - **Reader** — enough to restore versions already in the feed. - **Collaborator** — additionally allows saving a new version from an upstream source. A pipeline with only Reader restores fine until someone adds a brand-new dependency, and then fails on that one package, which is a confusing symptom worth recognizing. - **Contributor** — required to publish, e.g. `dotnet nuget push` or `NuGetCommand@2` with `command: push` and `publishVstsFeed`. ## Scope and cross-project access A **project-scoped** feed in project B is not automatically reachable from a pipeline in project A. Two settings interact: the pipeline's **job authorization scope** (a project-scoped token cannot represent the collection-level identity), and whether the feed grants a role to the identity that actually shows up. Organization-scoped feeds sidestep the first half but still need the role. If the same restore works from a developer laptop and fails in CI, this asymmetry — a human with broad access versus a narrowly scoped machine identity — is usually the reason. ## Reading the failure properly A few distinctions save time: - **401** means the request had no acceptable credentials — an identity or injection problem. - **403** means authenticated but not allowed — the role is missing or too low. - A **404 on a package** from a feed you can otherwise list is often not auth at all: the version genuinely is not there, and upstream either is not configured or could not save it. ## For self-hosted agents and other organizations Self-hosted agents use the same run token; nothing extra is needed for same-organization feeds. Reaching a feed in a *different* organization is the one case that does need explicit credentials — typically a service connection of the appropriate package type, referenced by the authentication task, rather than an inline token.