企业如何使用Google OAuth实现RBAC基于角色的访问控制

你觉得IAM和Identity Platform功能重叠，本质是没搞清楚这几个产品服务的完全不同的场景，边界非常清晰，不存在适用场景重叠：

• Google Workspace（原G Suite）：是企业管控内部员工账号、组织架构、用户组的核心身份源，90%以上将Google作为内部IdP的企业，所有员工身份、组织关系数据都存在这里，普通个人@gmail.com账号不在企业管控范围内。
• Google Cloud IAM：只用来管控Google Cloud（GCP）自身云资源的访问权限，比如谁能操作云服务器、谁能读存储桶、谁能查数仓数据，和你自研应用里的业务RBAC权限没有任何关系，不要往这个方向对接。
• Google Identity Platform：是面向开发者的认证托管服务，相当于你不想自己做账号密码存储、不想自己对接各类社交/企业登录源时，可以用这个服务快速搭认证层，它本身不存储企业内部的组织架构、用户组数据，只是个认证中转组件。

所有正经用Google做内部员工身份管控的企业，100%以Google Workspace作为唯一可信身份源，不会用个人Google账号、也不会用Cloud IAM作为业务权限的数据源，落地分两类场景：

• 内部自研系统场景
  1. 企业管理员先在Google Workspace后台给你的应用开通OIDC集成权限，配置授权范围，核心需要申请的scope是openid、email、profile以及https://www.googleapis.com/auth/cloud-identity.groups.readonly，不要申请多余权限，不然审批通不过。
  2. 企业管理员提前在Workspace里建好和业务系统对应的用户组，比如「报销系统-管理员」「报销系统-普通员工」「报销系统-审计」，直接把这些组和你系统里的RBAC角色做映射，绝对不要给单个用户直接绑角色，后期维护成本会完全失控。
  3. 不要等Google在ID Token里直接返回组信息，Google默认不会在ID Token里塞自定义的用户组、角色字段，这是新手最容易踩的坑。
• 多租户SaaS场景
  1. 你需要在产品里做企业自助对接配置页，引导客户的Workspace管理员完成OIDC参数配置，引导对方给你的应用开通组读取权限，让客户自己配置「自身Workspace里的哪个组对应你系统里的哪个角色」，映射规则存在你自己的业务数据库里。
  2. 不要尝试跨租户读取其他企业的Workspace数据，Google的权限边界会直接拦截这类请求。

首先纠正一个认知错误：你提到的从JSON Web Key（JWK）里提取角色/组信息是完全行不通的，JWK是Google公开的、用来给你验签ID Token合法性的公钥集合，里面不存储任何和用户权限相关的内容。
正确的获取流程是：

1. 用户完成OIDC授权回调后，你先用返回的授权码换取Access Token和ID Token，对ID Token做验签，拿到核心字段：用户唯一标识sub、用户邮箱、托管域名hd（也就是用户邮箱的企业后缀）。第一步必须先校验hd字段是不是企业备案的域名，直接拦截所有没有hd字段的个人@gmail.com账号，避免非企业账号混入内部系统。
2. 用上一步拿到的Access Token，调用Google Cloud Identity的Groups接口，查询当前用户所属的、在你提前配置的组-角色映射范围内的所有用户组，再根据映射规则把对应角色加载到用户的应用会话中即可。

实操提示：不要每次用户发业务请求都调用Google接口查组信息，很容易触发接口限流。在用户登录时查一次，把角色信息存在服务端会话或者缓存里，设置4-8小时的过期时间即可，有条件的可以对接Workspace的组变更Webhook，做权限的实时更新。

• 绝对不要把个人Google账号纳入企业内部RBAC体系，这类账号不属于企业管控范围，员工离职、转岗的时候根本没法自动回收权限，合规风险极高。
• 不要尝试把Google Cloud IAM的角色和你业务系统的RBAC角色做映射，Cloud IAM的角色只对应GCP资源权限，企业也不会给普通业务应用开Cloud IAM的读取权限，这类权限过大，合规审批根本过不了。
• 不要往ID Token里塞过多权限字段，Google的ID Token有大小限制，塞太多组信息会直接导致登录流程失败，权限映射规则存在自己业务侧是最稳妥的方案。

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