咱先直接给结论：很难，但不是完全不可能，不过Google有多层防护机制堵着这个漏洞：

• Google登录的核心验证逻辑是绑定应用的SHA-1/SHA-256指纹和包名组合，这俩信息会和你在开发者控制台里配置的严格比对，不匹配的话授权服务器直接拒绝发令牌。
• 另外，Google Play Protect会对应用做签名验证，伪造的应用要是没有合法签名，不仅很难通过Play商店分发，用户安装时系统也会弹出警告提醒风险。
• 还有用户层面的防护：登录时用户能看到应用名称和开发者信息，伪造的应用这些信息肯定和官方不一致，细心点的用户一眼就能察觉。

当然，要是攻击者拿到了你的应用签名密钥和包名（这可是核心机密，绝对不能泄露），那确实能造出通过验证的伪造应用，但这种情况属于内部泄露，不是常规的伪造场景。

底层逻辑：不止依赖SHA指纹和包名 #

Google登录发放令牌的流程里，SHA指纹和包名是关键验证项，但不是唯一的：

• 当你的应用发起登录请求时，会把包名、签名指纹还有客户端ID（开发者控制台生成的那个）一起发给Google授权服务器，服务器会先比对这些信息和你配置的是否一致。
• 就算令牌发下来了，你的后端服务在验证令牌时，还能调用Google的令牌验证API，确认令牌的受众（aud字段）是否匹配你的客户端ID，这又多了一层保障。

关于篡改应用的风险 #

有人修改你的源码、重新签名打包，确实能篡改应用内的逻辑，但要影响Google登录流程有不少限制：

• 如果攻击者用自己的签名重新打包，SHA指纹就和你控制台配置的不一样了，Google授权服务器直接拒发令牌，登录请求肯定失败。
• 要是真的有人拿到了你的签名密钥（这属于严重的安全事故），那他们确实能打包出通过验证的应用，甚至篡改登录后的请求逻辑（比如给你的服务器发伪造数据）。这种情况你得立刻吊销旧密钥，重新生成并更新控制台配置，同时通知用户紧急更新应用。
• 另外，为了防止后端接收篡改的数据，建议你在后端对令牌做严格验证，应用和后端通信必须用HTTPS，还可以加个请求体签名的机制，确保数据没被篡改。

内容的提问来源于stack exchange，提问作者Baturay Saran