Engineering and Developers Blog
What's happening with engineering and developers at YouTube
ClientLogin using Google Accounts
Tuesday, December 11, 2012
Long-time readers might remember a blog post from a while back entitled “
ClientLogin #FAIL
”, in which we covered the myriad ways in which your
ClientLogin
authorization attempts might result in an error. Even though ClientLogin has been officially
deprecated
since April 2012, and even though we’ve been recommending that developers switch to
OAuth 2
for longer than that, we know there are still a good number of legacy applications out there that still rely on ClientLogin.
If you are a developer of such an application, there’s another thing that you (and your users) will need to start watching out for: at some point in the future, we will start requiring that the username parameter passed to ClientLogin (i.e. what’s referred to as the
Email=
value in the
ClientLogin request
) correspond to the full email address of the
Google Account
that’s associated with an underlying YouTube channel. We’ve supported using Google Account email addresses with ClientLogin for many years now, ever since we started
linking
Google Accounts to YouTube channels, but old habits die hard, and many users still use YouTube usernames.
We haven’t yet determined a date for when we still stop supporting ClientLogin with YouTube usernames and will provide additional details when we know more about when it will take place. However, if you use ClientLogin, it’s not too early to start encouraging your application’s users to start providing their Google Account email addresses instead of their YouTube usernames when logging in. If you have the ability to update your existing application’s user interface, we recommend doing so to indicate that the username field should take a Google Account email address. If you have any online help materials or technical support for your software, update them to ensure that users know to provide their Google Account email address.
Users who log in via the YouTube.com web interface, or who go through the AuthSub, OAuth 1, or OAuth 2 web authorization flows will soon be required to use their Google Account email address instead of their YouTube username as well. This web-based transition will take place well before we deprecate YouTube usernames for ClientLogin, and it should be transparent to developers since Google controls the user interface for these flows. For more information, see this
help center article
.
As mentioned, we’ll have a follow-up post in coming months with more details about exactly when we’ll stop supporting YouTube usernames with ClientLogin. That post will also communicate the exact error message that ClientLogin will return when a YouTube username is used.
We’d like to close with one more plea: ClientLogin is deprecated, and is technically inferior to OAuth 2 in a number of important ways. Our new Google APIs client libraries provide first-class OAuth 2 integration that developers can take advantage of in their new code, or back port to their existing code. You will be doing your users a service and making their accounts more secure by transitioning from ClientLogin to OAuth 2.
Update (June 2013)
: The change mentioned in this blog post is now in effect. Attempts to use ClientLogin with a YouTube username will result in
HTTP 403 Forbidden
responses, with
Error=BadAuthentication
in the response body.
Cheers,
—
Jeff Posnick
,
YouTube API Team
ClientLogin #FAIL
Wednesday, March 30, 2011
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!
Update
: A
Google I/O 2011
session borrowed this blog post's title and covered similar material (though not YouTube-specific). Check out the
ClientLogin #FAIL session's
video embedded below:
—Jeffrey Posnick, YouTube API Team
Best Practices for User Authentication
Thursday, March 17, 2011
(Cross-posted from the
Google Code
blog.)
By now, many of you have seen our
recent announcement
regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.
There are three forms of authentication supported by almost all of Google’s APIs.
AuthSub
and
OAuth
(either version 1 or the newer
OAuth 2
) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication,
ClientLogin
, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
HTTP 403
error response from our servers with the following in error included in the response body:
Error=BadAuthentication
Info=InvalidSecondFactor
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to
generate an application-specific password
and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to
this article
for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though.
This guide
explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
By Jeffrey Posnick, Google Developer Relations
Update to the ClientLogin URL
Thursday, November 4, 2010
We want to let the developer community know about a change to the officially supported URL for YouTube API
ClientLogin
requests. Previously, developers who wanted to obtain authentication credentials via a username and password had to send their ClientLogin request to
https://www.google.com/youtube/accounts/ClientLogin
. The new URL that we encourage all developers to use is
https://www.google.com/accounts/ClientLogin
. This new URL has been functional for a while, and is the same URL that other Google APIs use for ClientLogin requests. Switching YouTube API ClientLogin traffic to the standard URL ensures that developers across all of Google’s APIs will see standard behavior when logging users in.
All of the details regarding this switch as well as best practices for performing ClientLogin requests can be found in our YouTube API
documentation
. There is one specific change in behavior that is worth calling out: responses from the new ClientLogin URL will not include the YouTube username of the authenticated user, which the old URL’s responses did provide. We encourage developers to take advantage of the username
default
when constructing YouTube API request URLs, which always refers to the currently logged in user.
We have no immediate plans to disable the old ClientLogin URL, but we do encourage developers to update their code at their earliest convenience to point to the new URL. We will post again with further details if and when the legacy URL is turned off.
Cheers,
-Jeff Posnick, YouTube API Team
Labels
.net
360
acceleration
access control
accessibility
actionscript
activities
activity
android
announcements
apis
app engine
appengine
apps script
as2
as3
atom
authentication
authorization
authsub
best practices
blackops
bootcamp
captions
categories
channels
charts
chrome
chromeless
client library
clientlibraries
clientlogin
code
color
comments
compositing
create
curation
custom player
decommission
default
deprecation
devs
direct
discovery
docs
Documentation RSS
dotnet
education
embed
embedding
events
extension
feeds
flash
format
friendactivity
friends
fun
gears
google developers live
google group
googlegamedev
googleio
html5
https
iframe
insight
io12
io2011
ios
iphone
irc
issue tracker
java
javascript
json
json-c
jsonc
knight
legacy
Live Streaming API
LiveBroadcasts API
logo
machine learning
mashups
media:keywords keywords tags metadata
metadata
mobile
mozilla
NAB 2016
news
oauth
oauth2
office hours
open source
partial
partial response
partial update
partners
patch
php
player
playlists
policy
previews
pubsubhubbub
push
python
quota
rails
releases
rendering
reports
responses
resumable
ruby
samples
sandbox
shortform
ssl https certificate staging stage
stack overflow
stage video
staging
standard feeds
storify
storyful
subscription
sup
Super Chat API
survey
tdd
theme
tos
tutorials
updates
uploads
v2
v3
video
video files
video transcoding
virtual reality
voting
VR
watch history
watchlater
webvtt
youtube
youtube api
YouTube Data API
youtube developers live
youtube direct
YouTube live
YouTube Reporting API
ytd
Archive
2017
Mar
Jan
2016
Nov
Oct
Aug
May
Apr
2015
Dec
Nov
Oct
May
Apr
Mar
Jan
2014
Oct
Sep
Aug
May
Mar
2013
Dec
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2012
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2007
Dec
Nov
Aug
Jun
May
Feed
YouTube
on
Follow @youtubedev