VS Code 扩展发布改用 Trusted Publishing：OIDC 换掉长期令牌后要核对什么

如果你正用 PAT（Personal Access Token，个人访问令牌）从 CI 发布 VS Code 扩展，这次变化真正要核对的不是“新令牌怎么配”，而是三件事：身份字段是否精确对上、私有仓库的激活窗口有没有走完、以及旧 PAT 什么时候才该删。微软在 2026 年 10 月 28 日的开发者博客中宣布 Visual Studio Marketplace 支持 Trusted Publishing，用联邦身份替代长期令牌（Microsoft for Developers 公告）。

换掉的到底是什么#

按公告的描述，过去自动化发布扩展需要把一个 Azure DevOps PAT 存进 CI/CD 的 secret 里；Trusted Publishing 改成由 CI 系统向 Marketplace 出示联邦身份，Marketplace 校验配置好的 GitHub 工作流策略或 Azure Pipelines 工作负载身份，发布工具再用这个已验证身份去发布，流程中没有 PAT 需要取用。

几个可以当作事实记下的点：

• GitHub Actions 场景下，Marketplace 签发的是 15 分钟后过期的临时凭据，而不是长期 secret。
• 公告明确说明，现有基于 PAT 的发布方式继续可用，可以按自己的节奏迁移。
• 整个过程中没有需要存储或轮换的发布凭据——这是公告给出的设计目标，不等于你的仓库里已经没有别的长期密钥。

第一点容易被误读：15 分钟说的是临时凭据的有效期，公告没有说明它是否覆盖整个发布作业的耗时。如果你的构建加发布流程较长，这个数字意味着什么，材料里没有答案，属于待核实项。

两条路径先分清，再动手#

公告把 GitHub Actions 和 Azure Pipelines 处理成了两种不同的接入方式，配置对象都不一样。动手前先确认自己走哪条：

把 Azure Pipelines 也去建一个 Marketplace policy，是公告专门提醒要避免的动作。反过来，GitHub Actions 只把身份加为 Contributor 而不建 policy，公告的步骤里也没有这种写法。

GitHub Actions：policy 的字段要“精确”#

公告要求登录 Visual Studio Marketplace，打开拥有该扩展的 publisher，进入 Trusted Publishing，展开 Create 后填写下面几项。注意公告在描述这些字段时反复用了“exact”（精确）这个词：

关于最后一行，可以给一条推断：既然公告强调“精确名称”，那么 policy 里填的 environment 与工作流实际引用的 environment 应当逐字一致。但公告没有说明“policy 留空而工作流引用了 environment”会怎样匹配，这一点材料未覆盖，不要凭直觉下结论。

同样属于推断的是：重命名仓库或工作流文件后，原 policy 大概率不再匹配，需要同步更新。公告没有直接讨论重命名场景，这条只作为排查时的方向，不作为已确认的规则。

私有仓库的 48 小时窗口

公告对 GitHub policy 的生命周期给了一段明确但容易跳过的说明：私有仓库新建的 policy 处于临时激活状态，有效期 48 小时；在这段时间内完成第一次成功的令牌交换，policy 才会永久激活；如果 48 小时内没有使用，policy 会过期，可以重新打开再获得 48 小时。

这带来一个很实际的操作建议：建完 policy 不要放着等下周再发版。要么当天就把发布工作流跑通，要么明知道会过期，回来重新打开一次。每个 policy 的状态和最后使用时间都可以在 Trusted Publishing 页面查看，核查时先看这里，比翻构建日志快。

公告只对“私有仓库”描述了这套临时激活机制，公开仓库的 policy 是否同样有 48 小时窗口、还是直接生效，材料没有说明，待核实。

迁移顺序：先并存，验证后再删 PAT#

公告给出的 GitHub Actions 迁移路径是四步：建 policy、给发布 job 加 id-token: write、把发布命令改成使用 OIDC、运行工作流确认 OIDC 发布成功。成功之后，才从工作流和仓库 secret 里移除 Marketplace PAT。

顺序是这段内容里最值得照做的地方。公告明确建议：在第一次 Trusted Publishing 运行验证通过之前，保留 PAT；迁移成功后再删掉那个已经不再使用的 secret，避免它被别的步骤误用。

下面是一段示意片段，未执行，只演示公告提到的 id-token: write 应加在发布 job 上；具体发布命令的 OIDC 写法请以官方文档为准，本次材料未给出命令细节：

# 示意，未执行；环境与具体命令需按官方文档核实
jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # 材料要求：为发布 job 增加此项
    steps:
      - run: <你的发布命令；改用 OIDC 的写法见官方文档>

Azure Pipelines 的迁移顺序在公告里是另一套：先配置 WIF 服务连接、把该身份加为 publisher 的 Contributor，再把发布步骤改为使用这个连接，等联邦发布成功之后才移除 PAT。同样，不需要在 Marketplace 建 policy。

上线前值得逐条核对的清单#

1. 路径选对了吗：GitHub Actions 走 policy，Azure Pipelines 走 WIF 服务连接，两者不混用。
2. owner 是 login 吗：Repository owner 填组织或用户的登录名，Repository 只填仓库名。
3. 工作流文件名对吗：填 .github/workflows 下的文件名，不是工作流显示名。
4. environment 一致吗：工作流引用 environment 时，policy 里的名称要逐字对应。
5. 私有仓库激活了吗：48 小时内跑通第一次令牌交换，之后在页面确认状态已转为永久激活。
6. 权限加在发布 job 上了吗：id-token: write 加在真正执行发布的 job 上。
7. PAT 删在成功之后了吗：首次 OIDC 发布验证通过前不要删；通过后及时删掉不再使用的 secret。
8. Azure 侧角色给了吗：服务连接背后的身份需要是 publisher 的 Contributor。

材料没有回答的部分#

以下几点在本次材料中没有依据，不要按“官方已经说明”来理解：

• GitHub Actions 的 15 分钟临时凭据，是从换取时刻起算还是从发布开始起算，以及长流程是否会受影响。
• 公开仓库的 policy 是否存在类似的激活窗口差异。
• 发布工具的具体版本要求与最低版本号。
• 失败排查的具体报错含义——公告只指向了官方文档的 troubleshooting 部分，本次材料未包含其内容。
• 基于 PAT 的发布方式是否会、何时会停止支持。

这些都需要回到官方文档与发布说明核对，本文不替它们下结论。可以确定的是：切换本身不复杂，真正容易出问题的是字段精确性、私有仓库的 48 小时窗口，以及删 PAT 的时机——把这三处核对清楚，剩下的多半是文档细节。