JSR OIDC Publishing Fails with InvalidIssuer on Organization-Owned Repository

[jaypatrick]

JSR OIDC Publishing Fails with InvalidIssuer on Organization-Owned Repository

Summary

Attempting to publish @bloqr/compiler-core from an organization-owned GitHub repository (BloqrAI/bloqr-core) to JSR using OIDC-based trusted publishing consistently fails with:

The provided OIDC token is invalid: InvalidIssuer (invalidOidcToken)

This occurs despite:

• Complete JSR scope/package recreation
• Fresh GitHub repo link in JSR package settings
• Correct GitHub OIDC issuer (https://token.actions.githubusercontent.com)
• No organization-level OIDC policies configured in GitHub (none exist)
• deno publish --dry-run validation passing successfully

Environment Details

• Repository: BloqrAI/bloqr-core (public, organization-owned)
• JSR Package: @bloqr/compiler-core (linked to repository)
• Deno Version: 2.x
• GitHub Actions OIDC Reference: https://docs.github.com/en/actions/reference/security/oidc

Reproduction

.github/workflows/publish-jsr.yml:

on:
  push:
    branches: ["main"]
    paths:
      - "src/adblock-compiler-core/**"
  workflow_dispatch: {}

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x
      - run: deno publish --dry-run  # ✅ Passes
      - run: deno publish            # ❌ Fails with InvalidIssuer

Investigation

1. GitHub organization settings show no OIDC policies configured (only placeholder/sample values exist)
2. Repository is public and properly linked in JSR
3. GitHub OIDC issuer claim matches standard format
4. Subject claim format may have changed (July 15, 2026 GitHub OIDC update for new repos)

Current Workaround

Using JSR Workflow Token authentication instead:

- name: Publish to JSR
  env:
    JSR_TOKEN: ${{ secrets.JSR_WORKFLOW_TOKEN }}
  run: deno publish

This works reliably but loses OIDC provenance attestations.

Questions for JSR Team

1. Does JSR support OIDC for organization-owned repositories? The docs don't clarify this limitation.
2. Is the July 15, 2026 GitHub OIDC subject claim format change affecting validation?
3. Are there additional OIDC policies needed at the JSR end for org-repo integration?

Desired Outcome

Clarification on:

• Whether org-owned repos are fully supported for OIDC publishing
• Required OIDC configuration (GitHub org-level policies, JSR settings)
• Provenance attestation support for token-based publishing

---

Workaround adopted: Token-based publishing with JSR_WORKFLOW_TOKEN org secret, scoped to @bloqr namespace. Documentation added at docs/jsr-token-authentication.md.

Original GH Issue

[jaypatrick]

One thing to note: The Github organizations were created after I created my JSR account by logging in with Github. Subsequently, a GH enterprise cloud instance was created to house the Orgs created.

I was able to publish from my personal GH repositories just fine initially w OIDC, then we formalized those PoCs as a viable commercial product, created the GH orgs, then created the GH enterprise. Linking the JSR scope/package to the Org repo succeeds on JSR

[jaypatrick]

Confirmed that token-based publishing succeeds, here is the published scope/package if you need to troubleshoot backend processes: https://jsr.io/@bloqr/compiler-core

We require provenance though, thus OIDC is a must-have. JSR is going to be our supply chain backbone.

[jaypatrick]

Root cause found — this isn't a JSR bug, but there's a real feature gap worth tracking

We finally tracked this down. It wasn't anything wrong on JSR's side, and it wasn't misconfiguration in our repo or org settings either — it was one level up, at the GitHub Enterprise account level.

Our GitHub Enterprise account ("Bloqr Systems") had "Use enterprise-specific issuer URL" enabled (Enterprise Settings → Policies → Actions → OIDC Configuration). That setting customizes the iss claim on every GitHub Actions OIDC token issued anywhere in the enterprise, appending the enterprise slug: https://token.actions.githubusercontent.com/bloqrsystems instead of the plain https://token.actions.githubusercontent.com. JSR's OIDC verifier (understandably) only trusts the plain issuer, so every token we presented was rejected as InvalidIssuer — nothing to do with our repo linking, package settings, or subject-claim format.

We confirmed this wasn't speculation: we independently hit the identical failure mode on crates.io's trusted publishing against the same repo at the same time, and crates.io's rejection message is more descriptive — it echoes the actual issuer string it received:

Unsupported JWT issuer: https://token.actions.githubusercontent.com/bloqrsystems

Same repo, same broken issuer, two independent registries rejecting it identically. Once we disabled the enterprise custom-issuer setting, both JSR and crates.io OIDC/trusted-publishing started working immediately — no changes needed on either registry's side. We've since published @bloqr/compiler-core@1.2.1 live via JSR OIDC to confirm end-to-end, enabled "Require Publishing from CI" on the package, and provenance now shows as verified.

Feature request

GitHub Enterprise Cloud's enterprise-specific-issuer setting is a legitimate hardening option (added for tenant-isolation reasons — see GitHub's docs), and it's reasonable to expect some customers will have it enabled without realizing it breaks every third-party OIDC "trusted publishing" integration that hardcodes the plain issuer string. It'd be great if JSR could optionally accept the enterprise-scoped issuer form (https://token.actions.githubusercontent.com/<enterprise-slug>) for repos/packages where that's expected — e.g. validated against a per-package or per-owner-configured enterprise slug, similar to how the repo link itself is already scoped. Right now the only way to discover the mismatch is to hit InvalidIssuer with no indication of why, which cost us a fair amount of investigation time (we initially assumed it was purely an org-level setting, since the enterprise level isn't somewhere you'd normally think to look).

At minimum, surfacing the actual rejected issuer string in the error (the way crates.io does) would have saved us a lot of the diagnostic work — that alone would make this class of failure self-diagnosable without needing to cross-reference against another registry's error message to find the pattern.

Since there's no JSR-side bug here, feel free to close this as a feature request / enhancement rather than a defect — happy to help however's useful if you want more detail on our specific Enterprise config.

[KnorpelSenf]

I think it's fair to keep this open until the error message is improved. That'll make it easier for others to debug their systems until JSR shows a proper error.