Generalized Trusted Publishers (OIDC for Any CI/CD Provider)

[ramongalate]

Select Topic Area

Product Feedback

Body

Hi npm team

First off: Trusted Publishers are a fantastic addition. Passwordless publishing via OIDC is exactly the direction the ecosystem needs to move in, and the GitHub Actions / GitLab CI integrations are genuinely best-in-class. This is a huge step forward for supply-chain security and developer ergonomics. 🙌

That said, the current implementation is artificially constrained to a small set of CI/CD providers. The underlying trust model you’ve built is powerful and generic, but today it’s only exposed through provider-specific integrations. This leaves out a large class of production-grade CI systems (e.g. Jenkins, Buildkite, CircleCI self-hosted, Azure DevOps Server, internal platforms, etc.) that already support OIDC and workload identity federation.

Problem

Today, teams using other CI/CD platforms (mine included) are forced to:

• Accept short-lived tokens with frequent rotation (e.g. 3-month granular tokens)
• Maintain custom secret rotation workflows
• Lose the security posture and UX benefits of passwordless publishing

This is particularly painful for organizations that have standardized on self-hosted CI (e.g. Jenkins) for regulatory, security, or architectural reasons.

Proposal

Expose a generalized “Trusted Publisher” interface that allows users to define arbitrary OIDC identity providers and trust conditions, rather than limiting configuration to a small fixed set of CI/CD platforms.

Conceptually, this would look like:

• Allow users to register an OIDC issuer (e.g. https://ci.example.com/oidc)

• Allow definition of trust conditions (issuer, subject, audience, repository/job identity, environment, etc.)

npm verifies the OIDC token at publish time and issues short-lived publish credentials, exactly as with GitHub Actions / GitLab CI

This mirrors how cloud providers (AWS, Azure, GCP) already handle workload identity federation.

Concrete Example (AWS-style Trust Policy)

Here’s what a generalized trust relationship looks like in AWS IAM today. This is a real-world pattern used for secure, passwordless access from CI/CD systems via OIDC (example sanitized with placeholders):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER_HOSTNAME>/oidc"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_PROVIDER_HOSTNAME>:aud": "sts.amazonaws.com"
        },
        "ForAnyValue:StringLike": {
          "<OIDC_PROVIDER_HOSTNAME>:sub": "<Job id/Org id/Sub-group id>"
        }
      }
    }
  ]
}

This model allows:

• Strong identity binding (job, project, environment, event type)
• No long-lived secrets
• Fine-grained scoping of who/what can publish
• Full compatibility with self-hosted or enterprise CI/CD platforms

npm’s Trusted Publishers already conceptually follow this model — the missing piece is exposing this trust configuration in a provider-agnostic way.

Why This Matters

Supporting generalized trusted publishers would:

-Dramatically improve npm’s security posture across enterprise users

• Reduce long-lived token sprawl and secret leakage risk
• Encourage broader adoption of passwordless publishing
• Unlock modern identity-native workflows for teams outside GitHub/GitLab
• Make npm’s security model align with industry standards (OIDC federation, workload identity)

Suggested UX Direction

One possible UI/UX flow:

“Add Trusted Publisher”

Choose:

• GitHub Actions (managed)
• GitLab CI (managed)
• Custom OIDC Provider (advanced)

For custom:

• OIDC issuer URL
• Expected audience
• Allowed subject patterns (regex or glob)
• Optional claims (repo, job, environment, ref, etc.)

This keeps the simple path simple while enabling advanced, enterprise-grade integrations.

Again, great work on Trusted Publishers — this is exactly the right direction. Opening this up to generalized OIDC trust would make npm’s publishing security model truly best-in-class across the entire CI/CD ecosystem, not just a subset of platforms.

If helpful, I’m happy to provide concrete implementation feedback or examples from real Jenkins / self-hosted OIDC deployments.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[dopry]

Under the hood in NPM this works... see my implementation here semantic-release/npm#1122.