GitHub Enterprise OIDC: The Hidden Blocker for Secure Trusted Publishing and Developer OKRs

The Unseen Friction: GitHub Enterprise OIDC and the Roadblock to Secure Publishing

In the relentless pursuit of secure software supply chains, OpenID Connect (OIDC) trusted publishing has emerged as a cornerstone. It promises to eliminate long-lived credentials, streamlining automated deployments while bolstering security. Yet, for many GitHub Enterprise Cloud users, this promise is hitting an unexpected snag, creating a frustrating dilemma between security best practices and operational efficiency. This isn't just a technical glitch; it's a systemic friction point that directly impacts team productivity, delivery timelines, and the ability to hit crucial developer OKRs.

A recent discussion on the GitHub Community forum, initiated by user makstech, highlights a critical issue: OIDC token exchange failures when GitHub Enterprise’s OIDC issuer includes an enterprise scope. This seemingly minor configuration difference has significant ripple effects across development and operations.

The Core Problem: Enterprise-Scoped OIDC Issuers and the 401 Wall

At the heart of the problem is GitHub Enterprise Cloud's include_enterprise_slug setting for its OIDC issuer. This feature, often enabled as a security best practice, scopes OIDC tokens by embedding the enterprise context directly into the issuer URL. Instead of the standard issuer URL, https://token.actions.githubusercontent.com, the OIDC token's iss claim becomes enterprise-scoped, appearing as https://token.actions.githubusercontent.com/ (note the trailing slash and space, as observed in the bug report).

The issue arises because popular package registries, such as npmjs.com (and PyPI, as noted in pypi/warehouse#17700), are currently configured to trust only the *standard* issuer URL. When a GitHub Actions workflow, using a token from an enterprise-scoped issuer, attempts to publish a package, the token exchange fails with a stark 401 Unauthorized error:

POST https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/%40my-scope%2Fmy-package
Status: 401 Unauthorized
Response: {"message":"OIDC token exchange error - unauthorized"}

This isn't a case of incorrect credentials or misconfigured claims; all other critical OIDC claims—repository, repository_owner, job_workflow_ref, and environment—are correct and match the trusted publisher configuration. The rejection is solely due to the subtle but significant difference in the iss claim format.

Beyond the Error: Impact on Productivity, Delivery, and Security Posture

This technical discrepancy isn't just a bug; it's a strategic impediment, forcing organizations into an unacceptable trade-off: either degrade their security posture by disabling include_enterprise_slug or endure broken trusted publishing workflows.

• For Dev Teams: This issue translates directly into frustration and wasted cycles. What should be a seamless, automated deployment becomes a manual intervention or a hunt for workarounds. This directly impacts developer OKRs focused on deployment frequency, lead time, and overall system reliability. Teams are forced to choose between security and shipping code efficiently.
• For Product, Project, and Delivery Managers: Unforeseen roadblocks like this derail release schedules and compromise delivery performance KPIs. The promise of faster, more secure deployments through OIDC is undermined, leading to delays and increased operational overhead. The need for a robust software measurement tool becomes critical to identify such bottlenecks and advocate for their resolution.
• For Technical Leadership and CTOs: The implications are even broader. Enabling include_enterprise_slug is a security best practice, designed to scope OIDC tokens and enhance cloud provider security (AWS, Azure, GCP). Being forced to disable it for npm or PyPI publishing introduces a vulnerability, weakening the overall security posture of the software supply chain. This isn't merely an integration issue; it's a challenge to maintaining supply chain integrity and adhering to modern security standards across the enterprise.

The core of the problem is that the enterprise-scoped issuers share the same JWKS signing keys as the standard issuer. The enterprise slug, which can be validated against the enterprise claim in the JWT, provides an additional layer of security, not a reason for rejection.

The Proposed Path Forward: A Collaborative Solution

The solution, as suggested by makstech, is clear and technically sound: package registries like npmjs.com and PyPI should be updated to accept OIDC tokens from enterprise-scoped GitHub Actions issuers. Specifically, they should:

• Accept issuer URLs matching https://token.actions.githubusercontent.com/.
• Optionally, validate the enterprise claim in the JWT to ensure it matches the expected slug.

This approach respects the security enhancements provided by GitHub Enterprise's configuration while enabling seamless trusted publishing. It requires collaboration between GitHub, which provides the OIDC tokens, and the registry providers, who consume and validate them.

Why This Matters for Your Organization

In an era where software supply chain attacks are a growing concern, the ability to securely and automatically publish packages without long-lived credentials is non-negotiable. OIDC trusted publishing is a powerful mechanism for achieving this, but its effectiveness hinges on seamless integration across the ecosystem.

Organizations striving for high performance KPIs and ambitious developer OKRs cannot afford to have their secure delivery pipelines hampered by integration friction. This issue highlights the critical need for platform providers and registry maintainers to align on security best practices and ensure their systems are interoperable. Advocating for and implementing these fixes is not just about convenience; it's about fortifying the foundations of modern software development and ensuring that security enhancements don't inadvertently become productivity blockers.