对用户进行身份验证

如果您的应用处理来自用户的请求,则最佳实践是只让允许的用户进行访问。用户通常没有您的 Google Cloud项目或 Cloud Run 服务的 IAM 权限。

我们区分两种类型的用户:

  • 最终用户:不一定属于您的组织的应用用户。他们通常需要为自己注册一个账号。
  • 内部用户:由您的组织管理员明确授予应用访问权限的用户。他们通常属于您的组织。

对最终用户进行身份验证

如果要使用电子邮件/密码、电话号码、Google、Facebook 或 GitHub 等社交服务提供方或自定义身份验证机制对用户进行身份验证,则可以使用 Identity Platform。使用 Firebase Authentication 类似于使用 Identity Platform。

您需要一个公共 Web 应用或移动应用来处理登录流程,然后对 Cloud Run 服务发出经过身份验证的 API 调用。此公共 Web 应用本身可以托管在公共 Cloud Run 服务上。

如需了解使用 Identity Platform 进行最终用户身份验证的完整教程,请参阅 Cloud Run 最终用户身份验证教程。

  1. 将代码添加到您的 Cloud Run 服务以验证 ID 令牌

  2. 公开部署 Cloud Run 服务

  3. 在项目中设置 Identity Platform

  4. 在 Web 应用或移动应用中执行以下操作:

    1. 使用适当的 Firebase Auth 客户端库来获取 ID 令牌:
    2. 将该 ID 令牌添加到服务请求的 Authorization: Bearer ID_TOKEN 标头中。

您可以使用以下任一方法访问用户个人资料信息:

对于使用此身份验证技术的应用的端到端演示,请遵循教程:Cloud Run 最终用户身份验证

对内部用户进行身份验证

对于内部用户身份验证,请使用 Identity-Aware Proxy

如需为 Cloud Run 服务设置 Identity-Aware Proxy,请参阅为 Cloud Run 配置 Identity-Aware Proxy

对于包含经过身份验证的 Cloud Run 服务的预检 CORS(跨源资源共享)请求,我们建议您为 Cloud Run 配置 IAP,而不是使用 IAM 身份验证。这样,您就可以将 IAP 配置为允许未经身份验证的 OPTIONS 请求,从而满足浏览器的预检检查要求,同时确保所有其他请求都经过身份验证。

即使 IAP 允许 OPTIONS 请求,您部署到 Cloud Run 的应用代码仍必须通过发送适当的 CORS 标头来分别处理预检请求和随后的实际请求。

如需了解如何使用 OAuth 2.0 向受 Identity-Aware Proxy 保护的 Cloud Run 服务对用户或服务账号进行身份验证,请参阅有关程序化身份验证的文档。