Cloud Run认证问题：Identity Token可用，Access Token为何报401？

为什么Access Token无法用于Cloud Run认证？ #

Cloud Run的IAM认证机制只接受Identity Token（ID Token），不支持直接使用Access Token，核心原因是两者的设计目标和结构完全不同：

• Access Token的作用是授权访问GCP的公共API（比如Cloud Storage、Compute Engine管理API），它的受众（aud字段）是GCP的统一API前缀（如https://www.googleapis.com/auth/cloud-platform），不绑定具体的Cloud Run服务。
• Identity Token是用来证明身份的凭证，它的受众必须严格匹配你的Cloud Run服务的URL（比如https://gcp.a.run.app），Cloud Run会验证这个aud字段是否与自身地址一致，同时检查令牌中的身份是否拥有roles/run.invoker权限。

你用gcloud auth print-access-token生成的令牌，受众是GCP公共API，不符合Cloud Run的认证要求，所以返回401未授权。

如何适配使用OAuth 2.0和Access Token的系统？ #

如果请求系统只能生成Access Token，可以通过以下两种方案适配：

方案1：让请求系统生成针对Cloud Run的Identity Token #

即使系统用的是服务账号密钥，也可以生成符合要求的ID Token：

• 用gcloud命令生成（适合有gcloud环境的场景）：

  gcloud auth print-identity-token --audiences=https://gcp.a.run.app --impersonate-service-account=your-service-account@your-project.iam.gserviceaccount.com
  

• 直接调用OAuth 2.0端点生成（适合无gcloud的场景）：用服务账号密钥签名JWT，然后向https://oauth2.googleapis.com/token请求交换ID Token，确保JWT的aud字段设为你的Cloud Run服务地址。

方案2：在Cloud Run服务中添加自定义认证中间件 #

如果无法修改请求系统的令牌类型，可以在服务内部添加认证逻辑：

1. 接收请求中的Access Token，调用GCP的Token Info端点验证令牌有效性：

   curl https://oauth2.googleapis.com/tokeninfo?access_token=<你的Access Token>
   

2. 从返回结果中获取身份信息（比如email字段对应服务账号邮箱），检查该身份是否拥有roles/run.invoker权限（可以通过调用IAM API或者预先配置权限列表实现）。
3. 验证通过后再放行请求到业务逻辑。

注意：这个方案需要自行开发和维护认证逻辑，建议优先选择方案1。

补充说明 #

Cloud Run确实不支持直接用Access Token进行IAM认证，这是GCP Serverless服务（包括Cloud Functions）的统一设计，目的是让认证更精准绑定到特定服务，避免Access Token的宽泛权限被滥用。如果请求系统能对接GCP元数据服务器生成ID Token，这是最符合GCP安全规范的方式。

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