我目前的工作大量使用 OAuth2/OIDC。现在越来越多地转向 GCP。我对使用 OIDC 令牌进行服务到服务通信有一些澄清问题，一个是高层次的，一个是战术性的：
问题：我正在将 Cloud Scheduler 作业保护到 Cloud Run 端点。我已经解决了这个问题（据我所知），但我非常困惑为什么 Google 会这样设置，希望得到澄清。不是挑战事物，只是寻求理解。感觉与我所知道的完全不同。我一直将 id_tokens 用于人类。
为什么他们选择 OIDC ID 令牌进行服务到服务通信？我在用户端使用过大量 OIDC，但从未在服务器到服务器端使用过。因此，获取用于服务器到服务器通信的 ID 令牌感觉非常奇怪。我希望有一个链接指向文档，解释服务器到服务器端的这种架构选择。我本来希望所有服务到服务通信都使用带有客户端凭据的 OAuth2 访问令牌，而不是 ID 令牌。我看到了他们的文档表明该平台使用了两者的混合
为什么受众字段是任意的？在 Cloud Scheduler 中，似乎只要我在项目中使用有效的服务帐户，我就可以在受众字段中输入任何值？我相信这是有原因的，谷歌人很聪明，但这感觉像是一个安全漏洞。我的意思是，受众可以是任何有效的网址（我能说的最好）。我可以将 Cloud Run 端点的受众放在不同的项目中并进行该调用吗？
显然，AuthN 和 AuthZ 之间存在分歧，因此 id_token 更多地与 authN 有关，但根据令牌请求验证的受众字段将表明可靠的 Authz。但由于它是任意的，我觉得受众的验证不可信，因为任何人都可以在那里放任何东西。请告诉我我遗漏了什么。
我希望这些问题有意义。我是 GCP 的新手，但喜欢我所看到的，但我的工作的一部分是找到事物的边缘，与我过去使用的东西相比，这些感觉很奇怪。
答案1
为什么他们选择 OIDC ID 令牌进行服务到服务通信？我在用户端使用过大量 OIDC，但从未在服务器到服务器端使用过。因此，获取用于服务器到服务器通信的 ID 令牌感觉非常奇怪。我希望有一个链接指向文档，解释服务器到服务器端的这种架构选择。我本来希望所有服务到服务通信都使用带有客户端凭据的 OAuth2 访问令牌，而不是 ID 令牌。
在 Google Cloud 中，有两种类型的授权。基于角色（OAuth 访问令牌）和基于身份（OIDC 身份令牌）。基于角色的授权提供基于角色的所有资源的访问权限。例如，查看者可以访问所有 Compute Engine 实例。这种类型的权限在项目/文件夹/组织级别进行管理。基于身份的授权提供对单个资源的访问权限。关键区别在于权限/角色的分配位置：在项目级别还是在资源级别。由于角色在资源级别的权限范围太广，因此您需要另一种方式。那就是身份。我授予约翰访问 KMS 密钥秘密2. 身份+权限存储在KMS密钥访问管理层。
为什么受众字段是任意的？在 Cloud Scheduler 中，似乎只要我在项目中使用有效的服务帐户，我就可以在受众字段中输入任何值？我相信这是有原因的，谷歌人很聪明，但这感觉像是一个安全漏洞。我的意思是，受众可以是任何有效的网址（我能说的最好）。我可以将 Cloud Run 端点的受众放在不同的项目中并进行该调用吗？
如果你的代码创建了身份令牌，则观众是必需的。某些 Google 管理的 OAuth 客户端 ID 允许忽略受众。由于身份和权限存储在资源中，因此调用不同的 Cloud Run 端点将无法通过身份检查。在我看来，受众字段是身份系统首先检查身份令牌是否应被批准用于 IAM 层的快速方法。
显然，AuthN 和 AuthZ 之间存在分歧，因此 id_token 更多地与 authN 有关，但根据令牌请求验证的受众字段将表明可靠的 Authz。但由于它是任意的，我觉得受众的验证不可信，因为任何人都可以在那里放任何东西。请告诉我我遗漏了什么。
身份令牌已签名。只有授权的服务和代码才能创建身份令牌。正如我在上一点中提到的，受众不提供权限或授予访问权限。这是基于身份令牌授权访问的一系列步骤中的一步。最终验证是在资源上分配的身份 + 权限。受众不授予任何这些权限，但可以用作过滤器来快速丢弃令牌。