我认为这可能会帮助你
http://apiblog.youtube.com/2011/03/clientlogin-fail.html
客户登录#FAIL
YouTube API 支持多种身份验证方案——AuthSub、OAuth 1 和 2 以及 ClientLogin——但在许多方面问题最大的是最后一种方法 ClientLogin。这篇博文将介绍 ClientLogin 尝试可能失败的一些方式，并在可能的情况下提供解决这些故障的方法。
不过，在我们开始讨论之前，有一点公共服务声明：考虑到使用 ClientLogin 时可能出现的所有问题，请考虑使用 YouTube API 支持的替代身份验证方法之一！AuthSub 尤其是 OAuth 2 很容易实现，并且不会受到我们将在 ClientLogin 中介绍的问题的影响。即使您正在编写一个供个人使用的小脚本，获取一个长期存在的 AuthSub 或 OAuth 2 令牌并将其重新用于身份验证也比硬编码 ClientLogin 的登录名和密码更可取。仅仅因为您的代码无法访问 Web 浏览器并不意味着 ClientLogin 是您唯一的选择——本指南涵盖了在这种情况下使用 OAuth 2 的技术。
有了这个，让我们调查一些失败！
场景 1：具有未链接 YouTube 帐户的用户尝试 ClientLogin。目前这种情况实际上不会导致失败，但在不久的将来会失败。正如最近在 YouTube 主博客上宣布的那样，所有 YouTube 帐户都必须链接到 Google 帐户，否则登录将开始失败——目前的计划是在 4 月底之前禁用未链接帐户的登录。唯一的解决方法是让您的用户将他们的 YouTube 帐户链接到 Google 帐户。如果他们从 Web 浏览器登录，无论是在 www.youtube.com 还是使用 AuthSub/OAuth，他们将完成关联帐户的步骤。请务必注意，虽然我们需要关联帐户，但我们将继续接受 YouTube 用户名或 Google 帐户电子邮件地址作为 ClientLogin 请求中的电子邮件参数。
场景二：已启用 OpenID 联合登录的用户尝试 ClientLogin。使用 OpenID 的联合登录是一种验证与特定电子邮件提供商（目前为 Yahoo! 和 AOL）上的电子邮件地址对应的 Google 帐户的新方法。它目前是在选择加入的基础上提供的，所以目前，仅仅因为某人的 Google 帐户与@yahoo.com 或@aol.com 地址相关联并不意味着他们正在使用联合登录。对于选择加入的用户，ClientLogin 将不再起作用。使用联合登录，所有登录请求都需要由身份提供者处理，并且 Google 的 ClientLogin 服务器无法代表用户将凭据中继到第三方服务器。因为 AuthSub 和 OAuth 的两个版本都是基于网络的，用户可以直接登录身份提供者的网站，然后将其重定向回 Google 的服务器，以发出适当的 AuthSub 或 OAuth 令牌。从 ClientLogin 迁移到 AuthSub 或 OAuth 是提供适用于 OpenID 帐户的身份验证的唯一方法。
场景 3：启用了两步验证的用户尝试 ClientLogin。这种情况，以及它导致失败的原因，在之前的博客文章中有详细介绍。重要的一点是，启用两步验证的用户需要为每个需要 ClientLogin 的应用程序生成应用程序专用密码，并提供该密码而不是他们的正常 Google 帐户密码。或者，使用 AuthSub 或 OAuth 允许您的用户直接使用他们的两因素凭据登录，从而获得更好的用户体验。
场景 4：用户在尝试 ClientLogin 时遇到验证码。这不是一个新的失败场景，但是没有正确处理它的开发人员经常忽略它。ClientLogin 文档包含有关您的应用程序应如何处理来自 ClientLogin 尝试的 CAPTCHA 响应的建议。如果您使用的是 AuthSub 或 OAuth，您的应用程序无需担心处理 CAPTCHA 的逻辑——它由标准的 AuthSub 和 OAuth 登录过程为您处理。
这似乎是一个详尽的失败场景列表，但随着我们继续迭代 YouTube 和 Google 帐户的登录体验，未来可能会出现更多“陷阱”。我们将尽最大努力让我们的开发者社区了解最新情况，但让您的应用程序永不过时的最佳方法是停止使用 ClientLogin！