为什么在Google API中将ClientLogin用于网络应用是个坏主意？
One*_*ema 7 authentication client login google-api
我今天刚拿起Google API,允许我们网站的某些用户将视频上传到我们自己的组织YouTube帐户.我不希望我们的用户知道我们的用户名和密码,而是在他们想要将视频上传到youtube时给他们提供选项.如果他们选择这样做,他们会选中一个复选框并点击提交按钮.
我一直在开发者指南中看到,ClientLogin对我来说似乎是实现我想要做的最佳选择,对于Web应用程序中的用户身份验证来说不是一个好主意."Web应用程序的AuthSub"似乎不是我想要实现的最佳机制!
关于该怎么做的任何想法？
谢谢
在使用了 google API 和其他视频服务提供商的 API 之后，我学到了很多有关身份验证的知识。oAuth 和 AuthSub 是 Google 用于向用户帐户验证第三方 Web 应用程序的两种方法。
这个过程一开始可能看起来很混乱，但是一旦你理解了它，它也不算太糟糕。下图显示了 AuthSub 流程。
- 当 Web 应用程序需要访问用户的 Google 服务时，它会对 Google 的授权代理服务进行 AuthSub 调用。
- 授权服务通过提供访问请求页面来响应。此 Google 管理的页面会提示用户授予/拒绝对其 Google 服务的访问权限。可能首先要求用户登录他们的帐户。
- 用户决定是否授予或拒绝对 Web 应用程序的访问。如果用户拒绝访问，他们将被定向到 Google 页面，而不是返回到网络应用程序。
- 如果用户授予访问权限，授权服务会将用户重定向回 Web 应用程序。重定向包含适合一次使用的授权令牌；它可以兑换为长期存在的代币。
- Web 应用程序通过请求联系 Google 服务，并使用授权令牌充当用户的代理。
- 如果 Google 服务识别出该令牌，它将提供所请求的数据。
http://code.google.com/apis/accounts/docs/AuthSub.html#AuthProcess
当您请求进行身份验证并且用户登录他/她的谷歌帐户时，在他/她授予您的应用程序在其帐户中执行操作的权限之前，如果您的域尚未向谷歌注册，则用户将获得一个令人讨厌的红框告诉他们要小心，因为他们要授予访问权限的应用程序尚未向他们注册。
与旧式用户名和密码相比，这些方法的优点（在我看来）如下：
- 增强用户的安全性：用户不必向您提供他们的用户名和密码，他们必须登录 Google，您将获得一个访问令牌，您将使用该令牌进行任何进一步的 API 调用。如果用户愿意，可以从 google 内部撤销对您的应用程序的访问权限。
- 该过程可以让用户确信您的应用程序是“合法的”。如果用户必须通过 google 登录并允许您的应用程序，那么如果您的域名已在 google 注册，那么看起来可能会很好。
- 令牌可以升级为会话令牌：这意味着您不必每次需要请求访问谷歌用户帐户时都要求用户登录，只需使用会话令牌（您必须安全地保存在某个地方）你就完成了。
- 一旦了解了该过程，对用户进行身份验证就非常简单。
- （未经验证）如果用户更改密码，您不必更新安全令牌。
- 最后，如果您使用 oAuth，您可以创建一个界面，让您在连接到其他 Web 服务（例如 Vimeo）时轻松验证用户身份！
综上所述，我想您应该明白为什么使用用户名和密码（这就是 ClientLogin 的作用）连接到用户帐户是一个坏主意。其他身份验证方法允许您执行相同的操作（请求访问）并添加许多优点。
有关如何使用 AuthSub 验证用户身份的代码可以在这里找到，它几乎是即插即用的。只需确保将 $_SESSION['sessionToken'] 保存到更永久的位置，例如数据库。
http://code.google.com/apis/youtube/2.0/developers_guide_php.html#AuthSub_for_Web_Applications