通过OAuth2.0流程模拟GCP用户身份的实现可行性咨询

你设计的这套适配Web应用的GCP OAuth2.0授权流程完全可实现，属于GCP原生支持的标准三方授权场景，不存在底层能力上的卡点。

这套方案本质走的是OAuth2.0授权码模式的三方授权流程，完全匹配你的需求：

• 用户触发登录时，你的Web应用构造授权请求跳转至Google授权服务，页面会清晰列出你申请的所有权限范围，用户明确点击同意后，应用才会拿到代表用户身份的访问凭证。
• 权限边界是自动对齐的，不需要你提前同步每个用户的GCP权限做动态scope适配：你只需要在授权请求中带上应用所有功能可能用到的GCP API对应的scope列表即可，后续调用GCP API时，Google会做双重校验：
  • 第一层校验用户是否已经向你的应用授予了对应scope的访问许可
  • 第二层校验用户本身绑定的GCP IAM角色是否具备当前操作的执行权限
    两层校验全部通过请求才会放行，应用永远只能代用户执行用户本身在GCP中有权限做的操作，不会出现越权。

• 如果你图省事，可以直接申请https://www.googleapis.com/auth/cloud-platform这个全量GCP访问scope，不需要逐个API单独申请scope。哪怕你拿了全量scope，实际可执行的操作还是严格受限于用户自身的IAM权限：比如授权用户本身只有云存储对象的只读权限，你拿他的access token永远没法删除计算引擎实例、修改VPC配置这类用户本身没权限的操作。
• 如果需要支持用户离线时应用也能代执行操作，构造授权请求时加上access_type=offline参数即可拿到refresh token，后续access token过期时可以自动续期，不需要用户反复登录授权。
• 应用后续新增功能需要调用其他GCP API时，只需要在授权请求里追加对应API的scope，老用户再次登录时只会看到新增权限的授权提示，不需要重复确认已经同意过的权限。
• Web场景部署时记得在OAuth客户端配置里填对授权回调地址，不然会出现授权完成后跳转失败的问题，直接用官方提供的服务端SDK对接即可，不需要自己手写token签名、刷新的重复逻辑。

注意：如果你的应用要对外发布给所有GCP用户使用，需要走Google的OAuth应用验证流程，不然用户授权时会看到「应用未验证」的安全提示；如果只是给组织内部用户使用，把应用标记为内部应用即可跳过公开验证流程。

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