HarmonyOS鸿蒙Next中建议明确 Testing API(含邀请码相关接口)的鉴权策略,并评估补充 Service Account 鉴权支持

HarmonyOS鸿蒙Next中建议明确 Testing API(含邀请码相关接口)的鉴权策略,并评估补充 Service Account 鉴权支持 我们在用 AGC API 做 HarmonyOS 应用的邀请测试 CI 自动化分发,整体流程是:

新建测试版本 → 添加软件包 → 更新测试版本(绑包 + 绑群组)→ 提交测试版本 → 查询当前版本分享链接 → 拼接群组邀请码 → 给外部用户扫码安装

主链路(Publishing API + Upload Management API)已经用 Service Account 接入并稳定运行;但在补"拼接邀请码"这一步时,发现一个鉴权能力上的空缺,想反馈一下。


一、业务场景

CI 触发后会自动调 Publishing API 查询测试版本 appInfo.shareLink,再调 Testing API 查询 / 生成群组邀请码,最终拼成 shareLink + invitationCode 供外部测试用户直接扫码使用,避免每次发版人工到 AGC 后台维护邀请码。

二、当前实测情况

用同一套 Service Account JWT(按 AGC 文档示例签 PS256,Authorization: Bearer ${JWT})调用以下两类接口,行为不一致:

  • GET /api/publish/v3/app-info?appId=&releaseType=6&versionId= → HTTP 200,正常返回 appInfo.shareLink
  • GET /api/app-test/v1/test-group/invitation-code?groupId= → HTTP 401,ret.code=205524993,msg=client token auth failed

改用 API Client(POST /api/oauth2/v1/token 用 client_credentials 换 access_token,再带 client_id / Authorization / appId)调同一个接口 → HTTP 200,正常返回 invitationCodes[]。

三、对应文档观察

  • 邀请码相关三个接口(生成 / 查询 / 停止)的 Header 章节只列了「API 客户端方式」和「OAuth 客户端方式」,没有「Service Account 方式」小节
  • 而支持 SA 的接口(例如 Publishing API 的查询应用信息)会明确列出 Service Account方式:Authorization: Bearer ${JWT}

文档与实测行为一致:Testing API 当前看起来整体只接 API Client / OAuth。

四、由此产生的问题

  1. 一个完整的 CI 分发流程被动要维护两套凭据:SA(跑 Publishing / Upload)+ API Client(跑 Testing API 邀请码)
  2. 两套凭据共存增加了密钥管理、轮换、泄漏面控制的复杂度
  3. AGC 官方近期一直在推 Service Account(更细粒度、更现代)作为主推鉴权方式,开发者难以判断「API Client / OAuth 是否仍是长期可用方案」,也就无法决定是否应该把邀请码相关流程长期固化在 API Client 上

五、希望工程师协助确认

  1. Testing API(特别是邀请码相关接口)是否计划支持 Service Account 鉴权?如有,是否有大致时间表?
  2. 旧的 API Client / OAuth 鉴权方式是否长期保留?是否有下线计划?如果会下线,是否会先在 Testing API 上补齐 SA 支持再下线?
  3. 在过渡期,对于"同一业务流程必须混用 SA + API Client 两套凭据"这种场景,官方的推荐做法是什么?

六、环境信息

  • 鉴权方式:Service Account(主链路) + API Client(被动引入,仅用于 Testing API 邀请码)
  • 测试发布方式:HarmonyOS 测试发布方式(releaseType=6,API≥10)
  • 测试类型:邀请测试(testType=3)
  • 涉及接口:
    • GET /api/app-test/v1/test-group/invitation-code
    • POST /api/app-test/v1/invitation-code
    • POST /api/app-test/v1/invitation-code/action/stop
  • 参考文档:https://developer.huawei.com/consumer/cn/doc/app/agc-help-test-api-add-invite-code-0000002236201342

更多关于HarmonyOS鸿蒙Next中建议明确 Testing API(含邀请码相关接口)的鉴权策略,并评估补充 Service Account 鉴权支持的实战教程也可以访问 https://www.itying.com/category-93-b0.html

4 回复

666的确有这个过渡期的风险在,不过官方已经明确推动Service Account替代API客户端,https://developer.huawei.com/consumer/cn/doc/appgallery-connect-guides/agc-applinking-obtain-apiauthorization-0000001321336068

大家做好切换的保护

更多关于HarmonyOS鸿蒙Next中建议明确 Testing API(含邀请码相关接口)的鉴权策略,并评估补充 Service Account 鉴权支持的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


从你贴的实测结果和文档结构看,邀请码相关 Testing API 当前确实更像只支持 API Client/OAuth 鉴权,而不是 Service Account JWT;短期不建议继续用 SA token 硬调这个接口。工程上可以先把 Publishing/Upload 和 Testing 的鉴权封装成两个 AuthProvider,CI 里用密钥管理服务分别保存、最小权限授权、独立轮换,并确保日志里不要输出 JWT、client_secret、access_token 或完整请求头。这个反馈点本身很明确:建议官方补一张各 API 支持的鉴权方式矩阵,并说明 API Client/OAuth 是否长期保留、Testing API 是否有支持 Service Account 的计划。

当前 HarmonyOS Next 的 Testing API(含邀请码相关接口)鉴权策略主要基于 OAuth 2.0 的华为账号授权,并未公开支持 Service Account 鉴权。邀请码接口需携带应用包名及签名证书进行身份校验。如需补充 Service Account 鉴权,需等待官方后续版本更新。

当前 Testing API(邀请码相关)仅支持 API Client / OAuth 鉴权,未开放 Service Account 方式,因此调用时出现 401 属于预期行为。这与文档说明一致:支持 Service Account 的接口(如 Publishing API)会单独列出 SA 鉴权小节,而 Testing API 文档只列了 API Client 和 OAuth 方式。

截至目前,华为尚未公开 Testing API 加入 Service Account 支持的时间表或路线图。API Client / OAuth 作为长期存在的鉴权方式,暂无下线计划,开发者仍可将其用于邀请码流程。

在 Service Account 补全前,同一 CI 流程混用两套凭据是必要的实现方式,尚无官方过渡期推荐方案。可持续关注 AGC 文档更新以获取最新鉴权支持状态。

回到顶部