我目前正在研究完全托管在谷歌云平台上的绿地项目的最合适的身份验证/授权方法。我写这个摘要是为了对我喜欢的方法进行一次理智的检查；就是否存在我不知道的任何考虑因素或不准确之处寻求反馈。我将感谢任何在实施相关战略方面有相关经验的人提供意见。
我的主要问题是：
- 如何管理或否定OIDC过程中的作用域？不应由用户授权适当的访问；这应该由创建用户的组织IT管理员设置
- G Suite IT管理员是否可以将参数应用于自动分配预定义"Google Identity/IAM"策略组/角色的用户(自定义和/或非自定义)
- 签署JWT/Google ID的G Suite用户是否与Endpoints+IAP直接兼容(不需要任何处理/重新编码)
- 这种方法将来是否会通过联合身份方法来适应外部用户，而不需要对现有流程进行重大重构(例如Firebase auth)
要求：
- Angular SPA将是应用程序的单一GUI，托管在GCP/G Suite上为该组织注册的同一域上
- SPA将使用GCP的api网关(端点)向GKE微服务(可能都在一个VPC内)发出请求&其他G Suite服务(驱动器等)
- Org-IT G Suite管理员可以创建用户&通过G Suite UI分配各种(预定义的)IAM策略组/范围，为用户提供对组织资源(G Suite服务和GCP托管的自定义api/应用程序)的最低权限访问
- 用户只能使用他们的orgs G Suite帐户"使用谷歌登录"SPA
- 如果用户已经登录到其组织谷歌帐户，则无需再次登录SPA
- 登录SPA时，用户凭据应随每个请求一起发送，微服务将使用这些凭据来授权自定义业务逻辑，并将这些凭据传递给Google Drive等G Suite服务(如果自定义业务逻辑失败，则利用api范围授权作为额外的安全层)
- 在遥远的未来，有可能允许组织外部的客户/用户利用各种联合身份提供商(Facebook、Twitter等)访问SPA&组织托管的资源(这不是当前的需求，但这是一个长期的战略目标)
我确定的两种最适合目的的方法是：
1)终点
谷歌使用IT应用程序登录以获取用户组织谷歌ID&，因为我们使用OpenAPI，即带有身份感知代理(IAP)的GCP端点来管理JWT令牌的身份验证。
优点：
- 在UI门户的内部用户之间建立了清晰的界限，&未来潜在的外部用户
- 没有供IT管理员管理用户的自定义代码
- 没有自定义代码来同步Firebase&G Suite用户、角色、权限等，或访问镜像的G Suite用户以获取凭据
OR，2)Firebase
Firebase身份验证，&编写代码，使用Firebase Admin SDK在G Suite中生成用户，限制对基于组织域的资源的访问。
优点/缺点与上面的端点相反，如果需要外部用户，则不需要两种单独的身份验证方法。
我倾向于终点法。。。
如何管理或否定OIDC过程中的作用域？不应该由用户授权适当的访问；这应该由设置创建用户的组织IT管理员
IAM成员(用户、组、服务帐户等)的权限在Google Cloud IAM中进行管理。作用域与OAuth一起使用，以限制IAM已分配的权限。最佳做法意味着分配所需的权限(不再分配)，而不将IAM与作用域结合起来。
G Suite IT管理员能否将参数应用于用户(自定义和/或不应用)自动分配预定义的"Google Identity/IAM"策略组/角色？
G Suite和Google Cloud是独立的服务。谷歌云支持G Suite作为身份提供商(IDP)。权限在Google Cloud IAM中控制，而不是在G Suite中控制。您可以将G Suite与Google Groups组合，将IAM成员放入组中，以便于IAM管理。
签署JWT/Google ID的G Suite用户会直接兼容吗使用端点+IAP(不需要任何处理/重新编码)？
Google帐户(G Suite)不为其成员帐户提供私钥。因此，您不能使用签名JWT。签名JWT是一种较旧的授权机制，用于服务帐户。用户凭据的正确方法是OAuth 2.0访问和标识令牌。对于管理员，可以使用具有"域范围委派"的服务帐户。
这种方法会通过联合身份来适应外部用户吗方法，在未来，不需要对现有流程进行重大重构(例如Firebase auth)？
这是一个很难回答的问题。谷歌云确实支持外部身份提供商，但我发现这充其量是个问题。您也可以使用身份同步，但这也没有很好地实现。如果您要走谷歌云路线，请使用G Suite作为您的身份提供商，并使用谷歌云IAM进行授权。
我认为你的问题缺乏的一个重要点是理解授权在谷歌云和谷歌API中是如何工作的。这些服务主要使用OAuth 2访问令牌和身份令牌。这因服务和所需访问类型而异。这意味着您的应用程序需要了解它正在访问的服务以及如何提供授权。我有一种感觉，你期待Firebase/Endpoints为你做这件事。
另一项是Firebase是谷歌云的一部分，只是谷歌云的子集。Firebase是一款很棒的产品/服务，但如果您计划在Firebase之外使用谷歌云功能，请使用G Suite和Cloud IAM进行身份验证和授权。
Angular SPA将是应用程序的单一GUI，托管在在GCP/G Suite 上为该组织注册的相同域名
我假设您所说的域名是指DNS区域(网站DNS名称)。这将使CORS和cookie管理更容易，但不是必须的。
SPA将使用GCP的api网关(端点)向GKE发出请求微服务(可能全部在一个VPC内)&其他G套件服务(驱动器等)
好的-我认为使用端点没有任何问题。然而，一个好的答案需要详细说明每件事是如何实际实现的。另一项是您提到了端点和G Suite服务。这些是非常不同的项目。端点保护你的HTTP端点，而不是其他谷歌服务。
Org-IT G Suite管理员可以创建用户&分配各种(预定义)IAM策略组/范围，通过G Suite UI，为用户提供最少对组织资源的特权访问(G Suite服务和GCP托管自定义api/应用程序)
Google Cloud IAM和G Suite授权是独立的授权系统。为了让G Suite成员管理Google Cloud IAM，他们需要通过其成员ID或组成员身份在Google Cloud IAM中分配角色。没有共享授权权限。
用户只能使用他们的orgs G Suite账户
除非配置SSO，否则Google帐户成员是唯一可以进行身份验证的成员。授权由谷歌云IAM管理。
如果用户已经登录到他们的组织谷歌帐户，他们不需要再次登录SPA
这取决于您的应用程序代码在请求中提供正确的授权标头。
登录SPA时，用户凭据应与每个请求，哪些微服务将用于授权自定义业务逻辑，以及将这些凭据传递给G Suite像Google Drive这样的服务(利用api范围授权如果自定义业务逻辑失败，则提供额外的安全层)
我不知道你所说的"用户凭据"是什么意思。您永远不应该访问用户的凭据(用户名/密码)。相反，您的应用程序应该管理OAuth访问和身份令牌，并将它们发送到后端进行授权。
在遥远的未来，有可能允许客户/用户，在组织外部，利用各种联合身份提供者(Facebook、Twitter等)访问SPA&组织托管的资源(这不是当前的要求，但这是一项长期战略目标)
我之前在回答中谈到了这一点。然而，让我建议明确思考需要授权的内容。对您的应用程序的授权与对您的也授权谷歌云服务的应用程序进行授权不同。例如，您可以使用Twitter进行身份验证，并使用单个服务帐户进行谷歌云授权。这取决于您需要完成什么以及您希望如何管理授权。
[更新]
你在问题中使用的一个术语是SPA。在传统的用例中，所有处理都是由浏览器中的应用程序完成的。这是一场安全噩梦。浏览器将可以访问用于授权和标识的OAuth令牌，这是不安全的。这也限制了应用程序生成刷新令牌的能力，这意味着一旦现有令牌过期(每3600秒)，用户将需要重新进行身份验证。对于这个问题的范围，我建议将您的应用程序重新思考为更传统的客户端/服务器设计。身份验证由服务器处理，而不是直接由客户端应用程序内部处理。在我提到服务帐户的部分中，我假设后端系统已经就位，因此客户端只有一个加密的会话cookie。
根据我的经验，
G-Suite作为Identity provide+Cloud IAP将与authn和authz合作，在前端进行用户级访问检查。请参阅此
然而，对于后端应用程序到应用程序的通信，我将推荐GCP中的服务帐户，请参阅。你也可以使用云IAP来做同样的事情，请参阅。然而，选择取决于您的用例和公司的安全准则和策略。