使用Trusted Signing提交签名请求时遇400错误及SharedTokenCacheCredential认证失败求助

• 清理Shared Token Cache缓存
  SharedTokenCacheCredential依赖本地缓存的令牌，缓存损坏或过期可能导致认证失败。手动清理缓存后重试：

  • Windows：删除%LOCALAPPDATA%\.IdentityService目录下的缓存文件
  • macOS/Linux：删除~/.azure/msal.cache文件

• 检查Trusted Signing角色的细粒度权限
  确认Trusted Signing Signer角色是直接分配到具体的Trusted Signing资源上，而非仅继承自父级资源组或订阅。部分场景下，继承权限无法满足签名请求的细粒度要求。

• 验证签名请求参数合法性
  400错误多伴随参数问题，重点核对：

  • 待签名文件格式是否为Trusted Signing支持的类型（如PE、MSI、MSIX等）
  • 请求中的signingProfileName是否与目标资源中的配置完全匹配（注意大小写敏感）
  • 文件哈希值是否正确，避免文件损坏或哈希计算错误

• 排查环境变量与配置冲突
  检查是否存在冲突的Azure认证环境变量（如AZURE_CLIENT_ID、AZURE_TENANT_ID），这些变量可能覆盖SharedTokenCacheCredential的默认上下文。通过以下命令确认：

  • Linux/macOS：echo $AZURE_CLIENT_ID
  • Windows：echo %AZURE_CLIENT_ID%
    必要时临时移除冲突变量后重试。

• 启用详细认证日志排查
  开启MSAL详细日志追踪认证过程：

  • .NET应用添加日志配置：

    using Microsoft.Identity.Client;
    var logger = new ConsoleLogger(LogLevel.Verbose);
    var pca = PublicClientApplicationBuilder.Create(clientId)
        .WithLogging(logger)
        .Build();
    

  • Python应用设置日志级别：

    import logging
    logging.basicConfig(level=logging.DEBUG)
    

  从日志中提取认证失败的具体错误代码或描述。

• 确认账号上下文一致性
  用Azure CLI命令az account show确认当前登录账号、租户ID与Trusted Signing资源所属租户一致。多账号场景下，通过az account set --subscription <订阅ID>切换到正确订阅后重试。

• 检查Trusted Signing资源状态
  在Azure门户中确认目标Trusted Signing账户处于正常状态，无暂停、限制或合规性警告。

• 测试基础认证连通性
  用SharedTokenCacheCredential尝试获取其他Azure资源（如存储账户）的令牌，若同样失败，说明问题出在认证组件本身。此时可重新登录Azure账号（az login），或更新MSAL相关依赖包到最新版本。

内容的提问来源于stack exchange，提问作者Marilee Turscak - MSFT