为 GCP 构建 OAuth 令牌的最佳方式是什么答案

【问题标题】：What is the best way to structure our OAuth tokens for GCP为 GCP 构建 OAuth 令牌的最佳方式是什么
【发布时间】：2019-02-15 04:42:52
【问题描述】：

我们有一个多租户设置，我们为每个客户（K-12 学区）提供服务。我们在我们的网站上为每个客户提供一个子域。我们为所有客户端使用一个 API/OAuth 令牌，但将它们的每个单独的登录回调添加到我们的令牌中。我们收到了来自谷歌的警告，内容如下

您的项目 abre-platform 在重定向 URI 和原始 URL 中有多个唯一域，其中许多具有不相关的应用程序。这直接违反了 Google API 服务：用户数据政策，该政策要求项目在请求访问 Google 用户数据时准确地向 Google 和我们的用户展示其身份和意图。

我们正在寻找有关在 google 中进行此设置的最佳方式的指导。谢谢。

我们的客户代表已告知我们要开立支持票。我们这样做了，他们将其路由到随机团队（如 GSuite）。最终，其中一位告诉我们获得帮助的最佳方式是在 SO 上提问。我觉得这很奇怪，但这里什么都没有。

【问题讨论】：

标签： google-oauth

【解决方案1】：

让我检查一下我是否了解您的情况。

您只有一个服务器
该服务器为多个域提供服务（school1.edu、school2.edu 等）
您正在为每个租户使用一个唯一的重定向 URL，（school1.edu/oauth，school2.edu/oauth）
Google 不喜欢它

您应该对所有租户的应用使用单一重定向 (myapp.com/oauth)。当您构建初始身份验证 URL 时，您可以设置一个名为 state 的参数，该参数通过流程保留。所以当谷歌重定向回你时，它会重定向到myapp.com/oauth?state=school1。然后您在/oauth 的服务器代码可以重定向到{state}.edu/homepage。

【讨论】：

或者，您可以为每个域创建一个单独的 Google Cloud 项目。如果您在 Google Cloud 项目级别将每个学校的州分开，那么如果您的用户已登录到 school1.edu，则不会有自动登录到 school2.edu 的风险。
是的，这就是我们的方案。这也是我们目前所想的。我们最初有一个像@user2705223 描述的设置，谷歌标记了它（维护起来很麻烦），所以我们切换到每个人的子域。在我们再次重做之前，我正在寻找一些官方指导，说明这是正确的方法。
是的。来自 Google 的关键信息是 OAuth 重定向 URL 必须与应用程序相关联，而不是与应用程序交付的任何客户端域相关联。不要子域，或者至少不需要子域。我的回答的关键是重定向到你的APP，然后有一个二次重定向到客户端域。