NuGet package source authentication: forcing credential refresh after API key expiration

Short answer

NuGet does retry a request through a credential provider when a source returns a 401 challenge — but the credential the provider returns is cached for the lifetime of the process, keyed by source URI. A second 401 in the same restore process does not reliably cause NuGet to re-acquire credentials. So the practical answer to your goal is: put the expiry logic inside the credential provider, and treat process restart as the only guaranteed way to drop a session-cached credential. There is no built-in per-source TTL setting.

Separating confirmed behavior from assumption

Your understanding is partly right and partly conflates two different mechanisms:

• Credentials stored in NuGet.config (via setapikey or <packageSourceCredentials>) are static. They are used as-is until you edit the file. Nothing refreshes them, and they may be stored in plaintext at user level — a poor fit for short-lived keys.
• Credentials from a credential provider plugin are acquired at runtime. NuGet invokes the plugin when a source challenges with 401, then caches the result in-process for that source. This is the mechanism designed for your use case.

One correction to your mental model: ICredentialsProvider is an internal NuGet SDK interface, not a public plugin contract. The supported extensibility point is the credential provider plugin model — a standalone executable discovered by NuGet (conventionally named credentialprovider.* on PATH) that communicates over stdio. Compiling against the internal interface will break across NuGet versions.

Getting predictable refresh for short-lived keys

1. Implement expiry in the provider. The provider should track token lifetime itself and return a fresh credential whenever it is invoked and the current one is expired or near expiry. The Azure Artifacts Credential Provider is the reference implementation of this pattern for Azure DevOps feeds.
2. Don't rely on NuGet to notice revocation. NuGet's retry path is keyed primarily on 401 challenges; a revoked key that surfaces as 403 may not trigger re-acquisition at all. If your feed returns 403 for revoked keys, the provider must handle renewal proactively rather than waiting for failure.
3. Restart the restore process to force a clean slate. dotnet nuget locals http-cache --clear clears the on-disk HTTP cache, but session-cached credentials live in the process. A new dotnet restore invocation is the reliable reset.

Verifying cached vs. fresh credentials

Run restore with detailed verbosity and have your provider log every invocation with a timestamp:

dotnet restore -v detailed
dotnet nuget locals all --list

Then expire the key mid-session and restore twice. If the provider log shows only one invocation, the second request used the session-cached credential — confirming that manual/process-level clearing is the recovery path, not automatic re-acquisition. Grep the detailed output for 401/403 responses and provider messages to correlate.

Caveats

Retry-and-recache semantics differ across NuGet 5.x/6.x and between nuget.exe, the dotnet CLI, and Visual Studio. Check your versions (dotnet --version) against the NuGet release notes for credential-provider changes before depending on exact behavior. The one diagnostic detail that would change this recommendation: which client (nuget.exe vs. dotnet CLI vs. Visual Studio) is failing, since their caching behavior is not identical.