📋 Description

Since OIDC support has become GA on npmjs.com we may want to consider what supporting it or a similar flow would look like both in the client & in the registry. Notably, our registry implementation could go even further then what GitHub has done in supporting a wider net of "trusted builders" &/or take a different approach entirely.

🎯 Problem Statement

People want both safer & easier publishing flows (two things that are usually at odds). Long-lived, granular access tokens & CI bot accounts have become common practice for teams wishing to limit their secrets surface area. OIDC moves this practice even further in this direction by eliminating long-lived tokens all together & instead blesses certain cloud providers & their compute environments as "trusted builders". This moves access management away from the package registry & packages themselves to compute environments which are associated with linked git repositories (effectively removing the need for user/identity management on the registry itself).

💡 Proposed Solution

Supporting OIDC may be the right solution to address both a safer & easier publishing flow but I also think we may discover many issues with it as elaborated in "Design Considerations".

🔄 Alternatives Considered

A release manager/staged publishes may also help achieve a similar step-up in terms of ease of publishing with more security guarantees then we have today with tokens.

🎨 Design Considerations

A couple of important notes:

ATO / Token Compromise is moved, not eliminated

First, the OIDC implementation by npm leverages "trusted publishers" but that just seems to move the token attack vector to those other platforms (ex. GitHub/Gitlab today). Maybe its less likely GitHub tokens will ever get exposed/leaked although I sort of doubt that given the prevalence of gh & how easy it is to get a valid GitHub auth token for a user/env even when dynamically generated in Codespaces/GitHub actions (ex. gh auth token happily spits out the token in any env).

Metadata & Identity Changes

Another important note/caveat is how GitHub decided to add support for OIDC publishing, which is by modifying the _npmUser object to allow non-user, build information.

A published package will always have the user's information associated with the publish in the manifest (ie. their npm username as well as email):

"_npmUser": {
  "name": "vltops",
  "email": "[email protected]"
}

but now you may not get a user but a set of build information:

"_npmUser": {
    "name": "GitHub Actions",
    "email": "[email protected]",
    "trustedPublisher": {
      "id": "github",
      "oidcConfigId": "oidc:64fee2b2-bef3-4ef4-b759-9fa8e27ab9e2"
    }
  }

This seems like a step backward in the case of strong identity guarantees with npmjs.com. This essentially creates an ambiguous hole in identity where there previously was an npm account associated with every published package. That seems like if there's a compromised publish that it's going to get harder to trace not easier. Today it's immediately understood who's account was taken over/compromised but tomorrow it will require long investigations traversing different platforms & relying on the integration vs. access means you may not be able to easily recover from compromise further upstream. Unpublishing bad versions or publishing new good versions will be tired to the same system that was likely compromised.

🔍 Research & Prior Art

• https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/
• https://docs.npmjs.com/trusted-publishers#supported-cicd-providers
• feat: adds support for oidc publish npm/cli#8336

📊 Priority Level

High - Significant impact

⚡ Estimated Complexity

Complex - 1+ weeks of work

✅ Definition of Done

• Feature implemented and working as described
• Unit tests written and passing
• Integration tests written and passing
• Documentation updated
• Code reviewed and approved
• Performance impact assessed
• Accessibility considerations addressed
• Security implications reviewed
• Backwards compatibility maintained

📎 Additional Context

No response