为何Google Cloud服务账户需同时配置角色与授权令牌范围？

在Google Cloud中创建服务账户时，需要为其分配访问特定API的角色；加载该服务账户的凭据时，又得指定要使用的API范围。通常这两者的权限范围是匹配的——比如给服务账户分配Cloud Storage和Pub/Sub的访问角色，之后加载凭据时也要指定这两类API的范围。

我想从设计理念层面理解：为什么要采用这种双重机制？尤其是当为服务账户新增API访问权限时，为什么必须同时更新角色和范围？

（注：我并非要寻求操作层面的解决办法，完全能接受同时更新两者的操作，只是好奇背后的设计逻辑。）

我之前查找过相关问题，但没找到能满足我好奇心的答案：

• 某Stack Overflow问题：针对用户账户解答OAuth2中scope和角色的区别，不适用于服务账户场景
• 某Stack Overflow问题：包含大量OAuth2技术细节，我无法完全理解
• 某Stack Overflow问题：仅解答特定认证问题，未涉及设计原因的说明

设计逻辑解析 #

1. 分层权限控制：粗粒度范围与细粒度角色的互补 #

API范围是粗粒度的权限边界，它定义了服务账户能访问的API大类（比如https://www.googleapis.com/auth/cloud-platform是全范围，storage-full-control是存储全权限），作用是快速划定凭据的权限上限，避免凭据被滥用访问超出预期的API领域。

而IAM角色是细粒度的权限集合，它精确控制服务账户在某个API内能执行的具体操作（比如roles/storage.objectCreator只能创建存储对象，不能删除）。这种分层设计让权限管理更灵活：范围先圈定“能碰哪些API”，角色再细化“在这些API里能做什么”。

2. 兼容OAuth2标准与GCP IAM体系的妥协 #

GCP的服务账户凭据基于OAuth2 JWT标准，而OAuth2原生就要求通过scope参数声明请求的权限范围——这是标准层面的要求，确保凭据的权限请求符合OAuth2的安全规范。

但OAuth2的scope无法满足GCP复杂的细粒度权限需求，因此GCP引入了IAM角色体系来补充。两者结合既遵守了行业标准，又适配了云平台的精细化权限管理需求。

3. 双重校验提升安全性 #

在GCP的权限校验流程中，会同时检查：

• 凭据的scope是否包含目标API的访问权限
• 服务账户的IAM角色是否具备目标操作的权限

只有两者都通过，请求才会被允许。这种双重校验相当于给权限加了两道锁：即使IAM角色配置有误（比如误开了过高权限），如果scope没包含对应的API范围，请求依然会被拦截；反之，如果scope开得太宽，但IAM角色没给具体操作权限，同样无法执行。

4. 历史遗留与向后兼容 #

早期GCP的权限体系是基于API范围设计的，后来才引入更灵活的IAM角色。为了兼容旧有服务和应用，GCP保留了scope的机制，同时叠加IAM角色实现更精细的控制。这种渐进式的架构升级，避免了直接废弃旧机制导致的兼容性问题。

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