你可能是因为Google Sign-In应该是一个快速的集成，结果你却在看一个凭证屏幕，困惑于为什么一个应用类型会给你一个客户密钥，而另一个却不会。这种困惑是正常的，尤其是当你使用Capacitor、Ionic、Electron或混合的web和native堆栈时。
实现中最容易忽略的部分就是破坏真正实现的那一部分： Google Client IDs 是平台相关的, 并且非 web 应用类型通常 不 会
通过设计而没有客户端密钥。如果您创建错误的凭证仅为了强制秘密进入流程，通常会以破坏 OAuth 设置的方式结束，这比应该的更难调试。
将您的应用程序连接到 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.
That distinction saves time early. It also prevents the common mistake of building a mobile login flow around a web credential just because the console showed more fields. If you’re implementing this in a Capacitor app, this guide on OAuth2 in Capacitor apps 是什么是Google Client ID
A
Google OAuth 2.0 client ID 是Google认证系统中的应用程序的公共标识符。Google将其描述为在请求Google身份验证端点时向Google身份验证端点请求访问令牌时应用程序的唯一用户名，并指出它与__CAPGO_KEEP_0__密钥不同，因为它用于OAuth流程中验证应用程序身份的令牌交换期间，正如在 is the public identifier for your application in Google’s auth system. Google describes it as the unique username for an application when requesting access tokens from Google authentication endpoints, and notes that it’s distinct from API keys because it’s used in OAuth flows to verify the app’s identity during token exchange, as explained in 一个图表说明Google Client ID作为应用程序的唯一标识符和安全层。.
简单的心理模型
把它想象成 Google客户端ID 问题就像你的应用的 公共用户名.
它告诉Google，这个请求来自这个注册的应用。这个信息在登录、同意、令牌交换以及任何流程中都很重要，流程中你的应用要求代表用户进行操作。客户端ID是你的应用和Google的认证服务器都能参考的。
人们容易混淆的是，这个凭证位于两个概念旁边，它们是不可互换的。
客户端ID OAuth中用来识别应用的
API密钥 用来识别某些API调用所涉及的项目，这些调用不涉及委托用户授权
客户端密钥 是用于安全可靠存储机密的客户端 ID，仅在流程和应用类型中使用。
许多破坏性集成的起因是有人将这些视为同一事物的变体。它们并不是。
客户 ID Google 在实践中的位置
如果您需要 使用 Google 登录 或 在实践中，客户 ID Google 的位置是使用客户 ID 来识别应用
使用同意屏幕来代表应用给用户
客户 ID 是前端使用的值，用于启动身份验证握手。Google 的文档还指出，应用必须在专用 Cloud Console 项目中注册，才能生成凭据，并且 Web 应用需要配置授权的 JavaScript 源或重定向 URI，包括完整的方案和主机名。
- 因此，设置感觉比生成简单密钥更严格。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. 这个选择并非是外观上的问题，它决定了应用程序的识别方式以及所需的支持配置。
对于一个 web 应用程序，预计需要输入：
- 已授权的 JavaScript 源
- 已授权的重定向 URI
这些值必须是精确的。对于一个 web 凭证，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
您的产品可能是用户看到的单个应用程序，但它是多个 OAuth 客户端对 Google 来说。
A web 应用程序，一个 安卓构建，一个 iOS构建，并且一个 桌面应用 它们不提供相同的安全性特性。它们不以相同的方式证明身份，并且它们不存储凭证在可信的环境中。Google通过为每个平台提供自己的应用注册模型来处理这一点。
这种分离是好的安全卫生习惯。如果一个平台的凭证设置被破坏或配置不当，其他平台不会自动暴露。
以下是实用的分离方案：
- Web 使用Web客户端ID和严格的源和重定向URI匹配。
- 安卓 使用一个与包标识和SHA1指纹绑定的Android客户端ID。
- iOS 使用一个与应用程序包标识绑定的iOS客户端ID。
- 桌面或Electron 通常使用安装或桌面式OAuth模式，而不是基于秘密的浏览器流程。
Google Client ID类型比较
| 应用程序类型 | 主要标识符 | 是否提供客户端密钥? | 关键用例 |
|---|---|---|---|
| Web | 授权JavaScript源和重定向URI | 通常是的 | 浏览器应用和后端辅助Web OAuth |
| Android | 包标识符加SHA1指纹 | 经常不 | 原生Android登录 |
| iOS | 应用程序包标识符 | 经常不 | 原生iPhone和iPad登录 |
| 桌面 | 已安装应用程序标识符 | 常常没有 | 包括 Electron 风格的本机流程的桌面应用 |
移动和桌面客户端的客户端秘密悖论
这就是许多教程所犯的错误。
移动和桌面开发人员经常期望每个 OAuth 客户端都带有客户 ID 和客户秘密。然后他们创建一个 Web 应用程序凭据，因为他们可以在控制台中看到一个秘密。流程看起来更完整，所以他们继续。后来，身份验证会以令人困惑的方式中断。 根据 __CAPGO_KEEP_0__ __CAPGO_KEEP_1____CAPGO_KEEP_2__ __CAPGO_KEEP_3__ __CAPGO_KEEP_4__
__CAPGO_KEEP_5__ 这个移动凭证不匹配的说明,非Web应用类型，如Android、iOS和安装应用程序，通常会接收客户端ID，但没有客户端密钥，原因是Google不希望在客户端软件中嵌入可供用户提取的机密信息。
这个设计选择是正确的。移动应用程序或Electron包不是安全的机密存储。
什么有效: 适用于公共客户端的本机或客户端侧OAuth流程。
什么不有效: 仅为了强制实施密钥而为移动应用程序创建Web凭证。
对于Capacitor团队，这通常会出现在两个糟糕的模式中:
- 应用程序启动一个基于浏览器的流程使用一个 Web客户端 然后尝试像机密服务器一样行为。
- 应用程序发送一个 客户 ID 从打包的 code 中获取，实际上这与将密钥隐藏在客户端中相反。
更好的方法是将移动和桌面应用程序视为 公共客户端。现代 OAuth 通常意味着使用不依赖于客户端内置密钥的流程。如果您的后端参与其中，请将机密操作保留在后端，并将本机应用程序限制为公共客户端应执行的操作。
另一个细微差别对于 Firebase 支持的 Android 登录很重要。在这种设置中， Web 应用程序类型客户 ID 作为后端服务器的 OAuth 客户 ID，而 Android 应用程序则保留其自己的平台特定身份。这种分离会使团队困惑，因为他们会在同一个项目中看到一个 Web 凭证和一个移动凭证，并且会假设一个会取代另一个。它不会。
如果您记住一个规则，请使用以下规则： 选择与 code 运行的客户端类型匹配的客户端类型，而不是您希望拥有的凭证形状.
保护您的 Google API 凭证
大多数 OAuth 事件并不是由复杂的攻击引起的。团队泄露凭证、过度广泛设置重定向设置或将密钥放入不应放入的位置都是如此。
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 管道中管理密钥的指南 也值得应用到您的身份验证设置。
它们还会审计元数据，而不仅仅是密钥。OAuthConsent 屏幕与用户看到的客户端身份相关。如果应用名称模糊或误导性，用户更有可能不信任提示或批准错误的应用。
安全不仅仅是隐藏密钥。它还要确保每次都有正确的应用身份、重定向目标和批准屏幕。
解决常见的客户 ID 错误
大多数 Google OAuth 失败都是由于设置错误引起的。错误文本可能不友好，但一旦您知道哪里看，问题通常是很直接的。
解决大多数失败的修复
redirect_uri_mismatch
您的应用程序正在发送一个不完全匹配已注册的 Web 客户端的重定向 URI。检查方案、主机、路径和任何尾随差异。对于 Web OAuth，精确匹配是安全模型的一部分。
invalid_client
这通常意味着应用程序发送了错误的客户端 ID、错误的客户端密钥或在不同平台之间混合了凭据。常见的例子是 Android 或 iOS 流程意外地在错误的地方使用 Web 凭据。
invalid_request
这一个很广泛，但在跨平台应用中经常指向不正确的认证参数或不适合客户端类型的流程。检查应用程序是否尝试在不应该的地方包含密钥，还是所选的 OAuth 流程期望的客户端类型不同。
Google Sign-In 在 Web 上工作但在移动设备上失败
首先要检查的是客户端类型。移动开发人员最常见的错误来源是创建一个 Web 应用程序客户端 ID 只为了获取客户端密钥，而实际上应该使用 Android 或 iOS 类型的客户端，这些类型通常省略密钥，正如在 客户端密钥不匹配的分解中解释的那样。如果您的实现包含在登录后进行令牌生命周期工作的代码，那么令牌撤销指南也很有用。Android 登录失败后凭据创建
双重检查 Android 客户端附加的 SHA1 指纹。如果签名身份与 Google 期望的不符，应用程序就无法正确证明所有权。
-consent 屏幕看起来不正确
Consent screen looks wrong
验证应用程序名称和与 OAuth 设置在控制台关联的品牌。用户授权看到的内容，因此错误的元数据会导致信任问题和支持噪音。
实践调试顺序很简单: 首先检查客户端类型，然后检查重定向设置，接着检查平台标识符，最后检查是否在流程中需要一个密钥.
如果您的团队部署 Capacitor 或 Electron 应用程序，授权错误很少会孤立。它们通常会在发布压力、回滚需求和环境特定修复中浮现。 Capgo 帮助团队在不等待商店审查的情况下将目标更新推送到应用程序 code 和资产，这使得更容易修复登录流程、回调处理和客户端授权问题。
