OIDC Authentication fails with checked-in config files present

[joniumGit]

Hello,

I will detail the issue for NPM and later add details for Cargo as well.

Basically, if you have an .npmrc in the repository root along with your package file and lockfile, npm will use it when Dependabot updates run.

Then, you define there a common default for all developers to use, so that they can pull credentials from the environment:

registy=example.com
//example.com/:_authToken=${NPM_TOKEN}

Then configure Dependabot to use OIDC with the custom registry for updates either on the org or repo level.

At least in the case of Cloudsmith, you will end up with a failing Dependabot update due to duplicate authorization. Npm tries to pass the header from the config file (Bearer as nothing in environment) and the proxy adds the api key header.

Same can be reproduced with e.g. Cargo when using token auth.

---

Proposed Solution

Strip any Authorization header at the proxy from the incoming requests at least if OIDC is configured.

This would solve all cases where the core passes incomplete auth information. It would break any case where someone relies on double authentication to pass data.

---

Effect

• This prevents me from sharing a ready to go npmrc with other developers in my team.
• It complicates CI as I need to write or copy the file for every workflow instead of having it where it should be.

---

Apologies for the formatting, will add more details and examples and clean up the issue when on a computer

[brettfo]

We discussed this and agree it would be a good idea for the proxy to strip any existing auth headers before adding our own. The only difference between your proposal and what we'd like to see is that all existing auth headers should be stripped, whether OIDC is configured or not, and probably for all package ecosystems. The idea being that the dependabot-core updater container shouldn't have any tokens/secrets/etc. and all authentication should happen via the proxy image. If you're using dependabot via GitHub that's what happens now and if you're manually invoking the dependabot CLI it's the same.