YouTube: ClientLogin #FAIL

The YouTube API supports a number of authentication schemes—AuthSub, OAuth 1 and 2, and ClientLogin—but
it’s that last method, ClientLogin, that is in many ways the most
problematic. This blog post will cover some of the ways ClientLogin
attempts can fail, and when possible, provide ways of working around
those failures.

Before
we get into that, though, a bit of a public service announcement: given
all the ways that things can go wrong when using ClientLogin, please
consider using one of the alternative methods of authentication that the
YouTube API supports! AuthSub and in particular OAuth 2 are
straightforward to implement and aren’t susceptible to the issues that
we’ll cover with ClientLogin. Even if you’re writing a small script for
personal use, obtaining one long-lived AuthSub or OAuth 2 token and
reusing that for authentication is preferable to hardcoding a login name
and password for ClientLogin. And just because your code doesn’t have
access to a web browser doesn’t mean that ClientLogin is your only
option—this guide covers techniques for using OAuth 2 in such scenarios.

With that out of the way, let’s investigate some failures!

Scenario 1: A user with an unlinked YouTube account attempts ClientLogin.
This scenario won’t actually lead to a failure as of right now, but it will in the near future. As was recently announced on the main YouTube blog, all YouTube accounts must be linked to a Google Account or else logins will start fail—the current plan is to disable logins for unlinked accounts towards the end of April.
The only workaround is to have your users link their YouTube account to
a Google Account. If they login from a web browser, either at www.youtube.com
or using AuthSub/OAuth, they’ll be taken through the steps to link
accounts. It’s important to note that while we are requiring linked
accounts, we will continue to accept either a YouTube username or a
Google Account email address as the Email parameter in the ClientLogin request.

Scenario 2: A user who has enabled to OpenID federated sign-in attempts ClientLogin.
Federerated sign-in using OpenID
is a new method of authenticating Google Accounts that correspond to
email addresses on specific email providers (currently Yahoo! and AOL).
It is currently being offered on an opt-in basis, so for the time being,
just because someone’s Google Account is associated with an @yahoo.com or @aol.com
address does not mean that they are using Federated sign-in. For the
users who have opted-in, ClientLogin will no longer work at all. With
Federated sign-in, all login requests need to be processed by the
identity provider, and Google’s ClientLogin servers cannot relay the
credentials to a third-party server on the user’s behalf. Because
AuthSub and both versions of OAuth are web-based, users can log in
directly on the identity provider’s site and have that redirect back to
Google’s servers to issue the appropriate AuthSub or OAuth token.
Migrating off of ClientLogin to AuthSub or OAuth is the only way to
provide authentication that works with OpenID accounts.

Scernario 3: A user who has enabled 2-step verification attempts ClientLogin.
This scenario, and the reasons why it will result in a failure, is covered in detail in an earlier blog post. The important takeaway is that a user with 2-step verification enabled needs to generate application-specific passwords
for each application that requires ClientLogin, and provide that
password instead of their normal Google Account password. Alternatively,
using AuthSub or OAuth allows you users to log in using their two
factor credentials directly, leading to a better user experience.

Scenario 4: A user encounters a CAPTCHA when attempting ClientLogin.
This is not a new failure scenario, but it’s often overlooked by developers who don’t properly handle it. The ClientLogin documentation
includes recommendations for how your application should handle CAPTCHA
responses from ClientLogin attempts. If you’re using AuthSub or OAuth,
your application does not need to worry about logic for handling
CAPTCHAs—it’s taken care of for you by the standard AuthSub and OAuth
login process.

This
may seem like an exhaustive list of failure scenarios, but as we
continue to iterate on the login experience for YouTube and Google
Accounts, chances are more “gotchas” will crop up in the future. We’ll
do our best to keep our developer community informed, but the best way
to future-proof your application is to stop using ClientLogin!

—Jeffrey Posnick, YouTube API Team

Leave a Reply

Your email address will not be published. Required fields are marked *

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image