authentication - 为什么在 Google API 中对网络应用程序使用 ClientLogin 是一个坏主意？

Question

我今天刚刚使用了 Google API，以允许我们网站的部分用户将视频上传到我们自己组织的 YouTube 帐户。我不希望我们的用户知道我们的用户名和密码，而是让他们选择是否要将视频上传到 YouTube。如果他们选择这样做，他们会选中复选框并点击提交按钮。

我在开发人员指南中一遍又一遍地看到，ClientLogin 在我看来是实现我想要做的事情的最佳选择，但对于 Web 应用程序中的用户身份验证来说并不是一个好主意。 “AuthSub for Web applications”似乎不是我想要实现的最佳机制!

有什么想法吗？

谢谢

Answer 1

在使用了 google API 和其他视频服务提供商 API 后，我学到了很多有关身份验证的知识。 oAuth 和 AuthSub 是 Google 用于向用户帐户验证第三方 Web 应用程序的两种方法。

这个过程一开始可能看起来很困惑，但是一旦你理解了它，它也不算太糟糕。下图显示了 AuthSub 流程。

1. 当网络应用需要访问用户的 Google 服务时，它会向 Google 的授权代理服务发出 AuthSub 调用。
2. 授权服务通过提供访问请求页面进行响应。此 Google 管理的页面会提示用户授予/拒绝对其 Google 服务的访问权限。可能会首先要求用户登录他们的帐户。
3. 用户决定是否授予或拒绝对网络应用程序的访问。如果用户拒绝访问，他们将被定向到 Google 页面，而不是返回到网络应用程序。
4. 如果用户授予访问权限，授权服务会将用户重定向回 Web 应用程序。重定向包含适合一次使用的授权 token ；它可以兑换为长期 token 。
5. 网络应用通过请求联系 Google 服务，并使用授权 token 充当用户代理。
6. 如果 Google 服务识别出该 token ，就会提供所请求的数据。

http://code.google.com/apis/accounts/docs/AuthSub.html#AuthProcess

当您请求进行身份验证并且用户登录他/她的 Google 帐户时，在他/她授予您的应用程序在其帐户中执行操作的权限之前，并且如果您的域尚未向 Google 注册，则用户会收到一个令人讨厌的红色框，告诉他们要小心，因为他们要授予访问权限的应用程序尚未向他们注册。

这些方法相对于旧式用户名和密码的优点(在我看来)如下:

1. 增强用户的安全性:用户不必向您提供用户名和密码，他们必须登录 Google，您将获得一个访问 token ，您将使用该 token 进行任何进一步的 API 调用。如果用户愿意，可以从 Google 内部撤销对您的应用程序的访问权限。
2. 该流程可以让用户确信您的应用是“合法的”。如果用户必须通过 Google 登录并允许您的应用，那么如果您的域名已在 Google 注册，可能会看起来不错。
3. token 可以升级为 session token :这意味着您不必在每次需要请求访问 Google 用户帐户时都要求用户登录，只需使用 session token (您必须安全地使用该 token )保存在某个地方)然后你就完成了。
4. 一旦了解了该流程，对用户进行身份验证就变得非常简单。
5. (未经验证)如果用户更改密码，您无需更新安全 token 。
6. 最后，如果您使用 oAuth，您可以创建一个界面，让您在连接到 Vimeo 等其他网络服务时轻松验证用户身份!

综上所述，我想您应该明白为什么使用用户名和密码(这就是 ClientLogin 的作用)连接到用户帐户是一个坏主意。其他身份验证方法允许您执行相同的操作(请求访问)并添加许多优点。

关于如何使用 AuthSub 验证用户身份的代码可以在这里找到，它几乎是即插即用的。只需确保将 $_SESSION['sessionToken'] 保存到更永久的位置，例如数据库。

http://code.google.com/apis/youtube/2.0/developers_guide_php.html#AuthSub_for_Web_Applications