ADF REST链接服务发布至Live模式后缺失AuthHeader引发403错误

问题原因 #

• ADF发布REST链接服务时，会对敏感凭据做加密处理。当你在authHeaders里引用Azure Key Vault密钥时，发布过程会把authHeaders替换成encryptedCredential，但这个加密逻辑存在缺陷，导致生产环境运行时无法正确解析Key Vault里的凭据，最终缺失认证头引发403错误。
• HTTP类型链接服务的凭据加密逻辑和REST不一样，不会触发这种字段替换，所以没这个问题。

解决办法 #

方法1：用ADF内置认证类型替代自定义authHeaders #

直接放弃在authHeaders里写Key Vault引用，改用REST链接服务自带的认证方式：

• 编辑REST链接服务，在认证设置里选API Key类型
• API Key名称填你之前用在authHeaders里的头字段（比如Authorization）
• API Key值选Azure Key Vault，关联对应的密钥
• 这种方式下，ADF发布时会正确处理凭据加密，运行时自动注入认证头，不会丢字段。

方法2：在管道活动里动态加认证头 #

如果必须用自定义authHeaders，就绕开链接服务层面，直接在调用REST的活动里设置：

• 先把REST链接服务里的authHeaders删掉，只保留基础配置
• 在Copy Data或者Web活动的Headers设置里，加动态内容：

  {
      "Authorization": "@concat('Bearer ', secret('你的密钥库名称', '你的密钥名称'))"
  }
  

• 这样直接在活动级别注入认证头，不会受链接服务加密逻辑的影响。

方法3：修正ARM模板的部署参数 #

如果用ARM部署，别在模板里硬写authHeaders，改用参数化的Key Vault引用：

• 在ARM模板的链接服务部分，用parameters来定义Key Vault相关参数
• 部署时通过参数文件传入密钥库名称和密钥名称
• 遵循ADF官方的加密凭据格式，避免自定义authHeaders字段

验证步骤 #

1. 修改后先在GIT模式下测试连接、预览数据，确保正常
2. 发布到生产环境后，检查链接服务的JSON，确认encryptedCredential存在
3. 运行管道，验证403错误是否消失

内容的提问来源于stack exchange，提问作者Filip Drzewiecki