【发布时间】:2014-11-08 02:22:41
【问题描述】:
背景
我想创建一个最终将安装在“无数”网络服务器上的 PHP 应用程序。 该应用程序将访问与 Web 服务器管理员 Google 帐户关联的 Google Drive(它基本上会在用户的云存储中写入一些文件)。因此,最终用户将授权我的 PHP 应用程序使用其 Google Drive 存储空间。这是通过连接 Google OAuth2 服务来完成的(通过 OAuth2 协议)。
所以基本上我必须创建一个 ClientID/Secret 对(代表我的 Google 帐户),用于执行授权流程。
Google 提供了 3 种授权方式:
- 用于网络应用程序(网络上的网络浏览器)
- 用于服务帐户(我的服务器到 Google 服务器)
- 对于已安装的应用程序(如 Android、iPhone)
(1) 可能是最好的选择,除了我必须定义一个 REDIRECT_URI 来发送授权代码。因为我的 APP 将安装在“无数”不同的服务器上,所以我事先不知道应该返回 Google 响应的协议、域名和路径(也是 URI)。如果我只在 3 台服务器上安装这个应用程序,我可以为每台服务器预先创建一个 ClientID/Secret 对。事实并非如此。
(2) 表示将我的 P12 私钥与 PHP 应用程序一起部署,我对此感到不舒服!
(3) 意味着让最终用户将授权令牌从 Google 网页复制/粘贴到我的应用程序 Web 界面中。我试图避免这样做。
当我事先知道 REDIRECT_URI 时,我已经使用方法 1 使其工作。我还在源代码中嵌入了 client_id/secret 对,因此整个授权过程是用户友好的。但这不适用于“无数”部署场景。
问题
我应该使用哪种方法以及如何使用它,以确保整个过程对我(作为开发人员)和客户端(Web 服务器管理员)来说都是安全的。请注意,授权过程不应涉及最终用户复制粘贴某些代码。我希望这一步对最终用户来说是透明的/用户友好的(当它可以自动完成时,没有人喜欢复制粘贴)。
我应该将我的 client_id/secret 嵌入到应用程序中还是完全错误?我想没有最终用户想在 Google Developer Console 中创建自己的 ClientID,对吧?另一方面,为什么我会将我的 client_id/secret 提供给未知的最终用户?
最后的想法
我可以在我的(开发人员)Web 服务器上创建一个代理应用程序,这样我的 PHP 应用程序(应该部署在“任何地方”)将授权请求发送到我的代理服务器(它已经有自己的 client_id/秘密)这反过来会将调用重定向到 Google OAuth 服务,然后 REDIRECT_URI 将授权代码返回给我的代理,最后我会将响应重定向回原始发件人(PHP 应用程序)。你怎么看?
@Edit:正如我之前已经说过的,代理将是一种解决方案。我已经成功了,它可以工作。我也从用户 pinoyyid 那里收到了相同的解决方案。也谢谢你的回答。
【问题讨论】:
-
正如 FB OAuth 登录流程所说,“您的应用程序密码永远不应出现在客户端代码中”。这只是加强了我上面的最终想法。