你可能是因为Google Sign-In应该是一个快速的集成，结果你却在一个凭证屏幕上苦苦挣扎，想知道为什么一个应用类型会给你一个客户密钥，而另一个却不会。这种困惑是正常的，尤其是当你使用Capacitor、Ionic、Electron或混合的Web和本机堆栈时。
实现中最容易忽略的部分就是破坏真正实现的那一部分： Google Client IDs 是平台相关的, 并且非 web 应用类型通常 不 会
通过设计而没有客户端密钥。如果您创建错误的凭证仅为了强制秘密进入流程，通常会以破坏 OAuth 设置的方式结束，这比应该的更难调试。
- 目录
- 连接您的应用程序到 Google 生态系统
- 在实践中，客户端 ID Google 的位置
- 平台特定的客户端 ID 配置
- 如何安全地存储您的 Google API 凭证
- 解决常见客户端 ID 错误
将您的应用程序连接到 Google 生态系统
许多团队在同一时间遇到这个问题。他们需要 使用 Google 登录或者他们想要对某些东西如 Drive 或日历进行用户批准的访问，而一个 API 键 suddenly 停止被认为足够。
这是因为用户登录和委托访问通过 OAuth 运行。Google 需要一种方法来识别 您的应用而不是仅仅被调用的 API 。鉴定此类凭证的凭证是 Google Client ID.
如果您正在使用跨平台代码库，混淆会迅速加剧。您可能有一个 web 前端、一个 Android 外壳、一个 iOS 应用和一个 Electron 构建的桌面应用。它们可能共享产品品牌和后端逻辑，但它们不应共享一个 OAuth 身份。
一个实际的 OAuth 设置通常会归结为几个实现问题:
- 您应该创建哪种应用类型
- 您是否需要客户端密钥
- 哪些重定向 URI 或起源必须完全匹配
- 如何在不混淆凭证的情况下连接移动和 web 流程
- Why a flow that works in the browser fails inside a native wrapper
实践规则： If your app is asking for user permission or sign-in, start by thinking in OAuth client types, not API keys.
这种区分可以节省早期的时间。它还可以避免在控制台显示更多字段的常见错误，即在移动端登录流中构建一个基于Web凭证的登录流。如果您正在在Capacitor应用中实现此功能，则有关 OAuth2 in Capacitor apps 的指南是应用端流程的有用陪伴。
What Is a Google Client ID
A Google OAuth 2.0 client ID 是Google认证系统中的应用程序的公共标识符。Google将其描述为在请求Google认证端点时向Google认证系统请求访问令牌时应用程序的唯一用户名，并指出它与API密钥不同，因为它用于OAuth流程中验证应用程序身份以交换令牌，正如在 Google Cloud's OAuth client documentation.
简单的心理模型
把它想象成 Google客户端ID 问题就像你的应用的 公共用户名.
它告诉Google，这个请求来自已注册的应用。这个信息在用户登录、同意、令牌交换以及任何涉及应用代表用户操作的流程中都很重要。客户端ID是应用和Google身份验证服务器都能参考的。
人们容易混淆的是，这个凭证位于两个概念旁边，它们是不可互换的。
客户端ID OAuth中用于标识应用
API密钥 用于标识某些API调用所涉及的项目，且不涉及委托用户授权
客户端密钥 是用于安全存储机密的保密对等体，仅在可以安全存储机密的流程和应用类型中使用。
很多破坏性集成都是因为有人把这些东西当作同一种东西来处理的。它们不是。
在实践中，客户 ID Google 如何运作
如果您需要 使用 Google 登录 或 在实践中，客户 ID Google 如何运作使用 Google 登录
或
在实践中，客户 ID Google 如何运作
- 使用 Google 登录
- 或是使用客户 ID Google 还是使用认证屏幕来代表应用？
- 使用正确的应用类型来确定一个密钥是否属于流程
如果您想了解应用身份和委托访问如何结合在一起的更广泛的概述 这篇关于应用授权的指南 是一个很好的复习资料。
如何创建和查看您的客户 ID
控制台路径已经发生了足够的变化，以至于开发人员经常认为自己在错误的地方。他们通常不是。Google 目前暴露了两条导航路线来这些凭据：新的 Google Auth Platform > Clients 路径和较旧的 APIs & Services > Credentials 路径，正如描述在 Google 的设置文档.
开始在正确的控制台区域
打开Google Cloud Console并选择或创建将拥有认证配置的项目。不要将认证分散在多个随机项目中，这会使后期审计和支持更加痛苦。
从那里，前往以下任何地方：
- Google Auth Platform > Clients
- APIs & Services > Credentials
如果您的团队看到不同的导航标签，这是预期的。Google已经将身份设置与其他API凭证表面分开。
创建凭证时不要限制自己
当您创建新OAuth客户端时，主要决策是 应用类型。Google要求您选择特定的类型，如 Web, Android, iOS, 或 Desktop. 这个选择并非是外观上的问题，它决定了应用程序的识别方式以及所需的支持配置。
对于一个网页应用程序，预计需要输入:
- 已授权的 JavaScript 源
- 已授权的重定向 URI
这些值必须是精确的。对于一个网页凭证，Google 期望完整的方案和主机名，例如 https://www.example.com,而不是一个松散的域概念。
对于移动平台，形状是不同的。Android 注册需要包级别的身份和所有权验证，而 iOS 使用自己的平台标识符。如果您正在结合 Google 认证与另一个认证层 这个 Capacitor 社交登录设置与 Supabase 是一个有用的例子，展示了这些部分如何常常结合在一起。
如果您想在点击过程中比较 UI，那么这是一种不错的视觉参考。
哪里可以找到它
创建后，客户 ID 将出现在项目的凭据列表中。同样的项目空间也是团队启用 API 和查看 OAuth 身份如何连接到同意屏幕的地方。注册的应用程序名称是用户在权限提示中看到的，这是为什么准确命名应用程序很重要的一个原因。
Google 会在长期内管理这些凭据。您可以返回到控制台来复制客户 ID、查看设置，并在适用时管理与该凭据相关的客户机密。
同意屏幕并不是装饰。它是信任边界的一部分。用户在那里看到的是应用程序名称，而不是内部项目的昵称。
平台特定的客户 ID 配置
破坏 Google 登录设置的最快方法是假设一个客户 ID 可以覆盖所有平台。它不能。对于多平台应用程序，每个平台必须注册自己的独特 OAuth 2.0 客户 ID，特别是 Android 设置需要 SHA1 指纹来验证所有权，正如在 这个平台设置参考.
为什么一个应用程序需要多个客户 ID
您的产品可能是用户看到的单个应用程序，但它是 Google 中的多个 OAuth 客户端。
A web 应用, 一个 安卓构建, 一个 iOS构建, 并且一个 桌面应用 它们不具备相同的安全性特性。它们不以相同的方式证明身份，并且它们不全部将凭据存储在可信的环境中。Google通过为每个平台提供自己的应用注册模型来处理这一点。
这种分离是好的安全习惯。 如果一个平台的凭据设置被破坏或配置不当，其他平台不会自动暴露。
以下是实用的分离方案：
- Web 使用Web客户端ID和严格的源和重定向URI匹配。
- 安卓 使用一个与包身份和SHA1指纹相关联的Android客户端ID。
- iOS 使用一个与应用程序包标识符相关联的iOS客户端ID。
- 桌面或Electron 桌面或Electron应用程序通常使用安装或桌面式OAuth模式，而不是基于秘密的浏览器流。
Google客户端ID类型比较
| 应用程序类型 | 主要标识符 | 是否提供客户端密钥? | 关键用例 |
|---|---|---|---|
| Web | 授权JavaScript源和重定向URI | 通常是的 | 浏览器应用和后端辅助Web OAuth |
| Android | 包标识符加SHA1指纹 | 经常不是 | 原生Android登录 |
| iOS | 应用程序包标识符 | 经常不是 | 原生iPhone和iPad登录 |
| 桌面 | 已安装应用程序标识符 | 常常没有 | 包括 Electron 风格的本机流程的桌面应用 |
移动和桌面客户端的客户端秘密悖论
这就是许多教程所犯的错误。
移动和桌面开发人员经常期望每个 OAuth 客户端都带有客户 ID 和客户秘密。然后他们创建一个 Web 应用程序凭据，因为他们在控制台中才能看到一个秘密。流程看起来更完整，所以他们继续。后来，身份验证会以令人困惑的方式中断。 根据 client ID 和client secret 。然后他们创建一个 Web 应用程序凭据，因为他们在控制台中才能看到一个秘密。流程看起来更完整，所以他们继续。后来，身份验证会以令人困惑的方式中断。 Web 应用程序
凭据 这个移动凭证不匹配的说明,非Web应用类型，如Android、iOS和安装应用通常会接收到客户端ID但没有客户端密钥，意图如此，因为Google不希望在客户端软件中嵌入可供用户提取的机密信息。
这个设计选择是正确的。移动应用或Electron包不是安全的机密存储。
什么有效: 适用于公共客户端的本机或客户端侧OAuth流程。
什么不有效: 仅为了强制实施机密而为移动应用创建Web凭证。
对于Capacitor团队，这通常会出现在两个糟糕的模式之一中:
- 应用程序启动一个使用 web客户端 然后尝试像机密服务器一样行为。
- 应用程序发送一个 client secret 从打包的code中获取，实际上这与将 secret 隐藏起来的目的相矛盾。
更好的方法是将移动和桌面应用程序视为 公共客户端。现代 OAuth 通常意味着使用不依赖于客户端中隐藏的 secret 的流程。如果您的后端参与，务必将机密操作保留在后端，并将本机应用程序限制为公共客户端应做的事情。
另一个细微差别对于 Firebase 支持的 Android 登录很重要。在这种设置中， Web 应用程序类型的客户 ID 作为后端服务器的 OAuth 客户 ID，而 Android 应用程序保留自己的平台特定身份。这种分离会使团队困惑，因为他们会看到同一个项目中同时存在一个 Web 凭证和一个移动凭证，认为一个会取代另一个。它不会。
如果您记住一个规则，请记住这个规则： 选择与code运行的客户端类型匹配，而不是您希望拥有的凭证形状.
保护您的 Google API 凭证
大多数 OAuth 事件并不是由复杂的攻击引起的。团队泄露凭证、过度广泛的重定向设置或将 secret 放入不应放入的地方都是常见的错误。
Google的OAuth指南强调，客户端ID和密钥应被视为私有数据，针对web应用，客户端ID将被强制与预注册的重定向URI进行匹配。如果重定向URI不严格匹配，Google将拒绝请求。该源绑定是token劫持保护的一部分，正如在 OAuth.com的客户端注册指南中所述.
立即锁定什么
如果你只做几件事正确，那就做这些：
- 绝不将客户端密钥在应用程序中code中发送。 Web包，移动二进制文件和Electron包是可由用户检查的。
- 注册准确的重定向URI。 够近是不够的。Google对web流程进行严格匹配验证。
- 保持源代码紧密。 不要仅仅为了克服设置阻力而授权广泛的域名。
- 分离平台凭证。 不要让便利性将 Android、iOS 和 Web 混合到一个凭据中。
一个操作细节容易被忽略。Google 允许团队为现有客户 ID 生成新密钥并禁用旧密钥。这在密钥被泄露时或您正在优化部署流程时很重要。
安全团队实际上做什么
那些避免麻烦的团队会对 OAuth 凭据进行处理，像其他生产密钥一样对待。
它们将 Web 客户端密钥保留在后端，通过环境管理注入它们，并审计谁有控制台访问权限。如果您正在清理发布管道，这篇关于 管理 CI/CD pipeline 中的密钥 的指南也值得应用到您的认证设置中。
它们还会审计元数据，而不是仅仅关注密钥。OAuth 同意屏幕与用户看到的客户端身份紧密相关。如果应用名称模糊或误导性，用户更有可能不信任提示或批准错误的应用。
安全不仅仅是隐藏一个密钥。它还要确保每次都正确的应用身份、重定向目标和批准屏幕一致。
解决常见的客户 ID 错误
大多数 Google OAuth 失败都是由于设置错误引起的。错误文本可能不友好，但一旦您知道哪里看，问题通常是很直接的。
解决大多数失败的修复
redirect_uri_mismatch
您的应用程序正在发送一个不完全匹配已注册的 Web 客户端的重定向 URI。检查方案、主机、路径和任何尾随差异。对于 Web OAuth，精确匹配是安全模型的一部分。
invalid_client
这通常意味着应用程序正在发送错误的客户 ID、错误的客户端密钥或在不同平台之间混合凭据。常见的例子是 Android 或 iOS 流程意外使用了 Web 凭据的错误位置。
invalid_request
这很宽泛，但在跨平台应用中，它经常指向 malformed 的认证参数或不符合客户端类型的流程。检查应用程序是否尝试在不应该的地方包含密钥，或者所选的 OAuth 流程是否期望不同的客户端类型。
Google Sign-In 在 Web 上工作，但在移动设备上失败
首先要检查的是客户端类型。移动开发人员最常见的错误来源是创建一个 Web 应用程序客户端 ID，只为了获取客户端密钥，而实际上应该使用 Android 或 iOS 类型，这些类型通常省略密钥，正如在 中解释的那样。如果您的实现包括在登录后进行令牌生命周期工作，那么
中关于令牌撤销的指南也是很有用的。
Android 登录失败后凭据创建
双重检查 Android 客户端附加的 SHA1 指纹。如果签名身份与 Google 期望的不符，应用程序就无法正确证明所有权。
验证应用程序名称和与 OAuth 设置在控制台关联的品牌。用户授权看到的内容，因此错误的元数据会导致信任问题和支持噪音。
正确的调试顺序很简单: 首先检查客户端类型，然后检查重定向设置，接着检查平台标识符，最后检查是否在流程中需要一个密钥.
如果您的团队部署 Capacitor 或 Electron 应用程序，授权错误很少会孤立。它们通常会在发布压力、回滚需求和环境特定修复中出现。 Capgo 帮助团队在不等待商店审查的情况下将目标更新推送到应用程序 code 和资产，这使得更容易修复登录流程、回调处理和客户端身份验证问题。
