Cloud Run部分用户遇403权限不足错误，其余用户正常求助

• 检查OAuth2 Scope配置差异
  虽然两个账号的OIDC令牌标准字段（iss/aud/azp/hd）一致，但要确认测试账号获取令牌时请求的scope是否包含Cloud Run所需权限。比如Cloud Run调用需要https://www.googleapis.com/auth/run.invoker或更宽泛的cloud-platform scope。个人账号可能在授权时默认获取了完整权限，而测试账号的OAuth客户端或Firebase Auth配置里限制了scope，导致令牌缺少必要权限。直接用jwt.io解析两个令牌，对比scope字段（如果存在），或者去Firebase Auth的授权设置里看测试账号所在用户组的scope限制。

• 验证Cloud Run的IAM权限绑定
  别只盯着服务账号权限，重点看用户身份本身是否被授予Cloud Run的roles/run.invoker角色。个人账号可能被直接添加到Cloud Run的IAM允许列表，而测试账号所在的域、用户组或者身份池没被授权。操作步骤：进入Cloud Run服务的IAM页面，检查有没有针对测试账号邮箱、所在域或用户组的roles/run.invoker绑定；如果用了Firebase身份池，还要确认身份池的服务账号有run.invoker权限，且身份池规则允许测试账号的身份通过。

• 排查Firebase Auth的自定义声明/用户属性
  测试账号可能缺失后端依赖的自定义声明，比如代码里靠roles这类自定义字段判断权限，而测试账号没配置这些。虽然标准OIDC字段一致，但自定义声明可能存在差异。去Firebase控制台查看测试账号的用户属性，或者在后端打印完整的令牌payload，对比两个账号的自定义字段。

• 确认Cloud Run的IAP配置（如果启用）
  如果开了身份感知代理（IAP），除了OIDC令牌，IAP还会验证用户会话和权限。测试账号可能没在IAP的权限列表里，或者会话异常。进入Cloud Run服务的安全页面，确认IAP是否启用，然后查看IAP的权限绑定，确保测试账号所在身份有roles/iap.httpsResourceAccessor角色。

• 检查令牌有效期与刷新机制
  测试账号的令牌可能过期或刷新失败，导致请求用了无效令牌。前端虽然自动刷新，但会话丢失等情况可能导致使用旧令牌，而旧令牌的权限或scope已被撤销。在后端加日志，记录请求令牌的exp（过期时间）字段，对比两个账号的令牌有效期是否正常。

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