Why is it a bad idea to use ClientLogin for web apps in the Google API?

Question

I just picked up the Google API today to allow some users of our site to upload videos to our own organization YouTube account. I Don't want our users to know our user name and password, but rather give them the option if they want to upload videos to youtube or not. If they choose to do it, they check on a check box and hit the submit button.

I keep seeing over, and over in the Developers guide that ClientLogin, which to me looks like the best option to implement what I want to do, is not a good idea for user authentication in web applicaitons. The "AuthSub for web applications" doesn't seem to be the best mechanism for what I want to implement!

Any ideas on what to do?

Thank you

Answer 1

I've had the same problem, and I ended up using ClientLogin. If you do not want your users to see any part login process, this will do.

I do not know if there is a better way of doing this with AuthSub or other authentication methods.

Answer 2

After playing with the google API and other video service providers API's I have learned a lot about authentication. oAuth and AuthSub are two methods that google uses to authenticate third party web applications to a user account.

The process may seem messy at first, but once you understand it, it is not too bad. The following image shows the AuthSub process.

1. When the web application needs to access a user's Google service, it makes an AuthSub call to Google's Authorization Proxy service.
2. The Authorization service responds by serving up an Access Request page. This Google-managed page prompts the user to grant/deny access to their Google service. The user may first be asked to log into their account.
3. The user decides whether to grant or deny access to the web application. If the user denies access, they are directed to a Google page rather than back to the web application.
4. If the user grants access, the Authorization service redirects the user back to the web application. The redirect contains an authorization token good for one use; it can be exchanged for a long-lived token.
5. The web application contacts the Google service with a request, using the authorization token to act as an agent for the user.
6. If the Google service recognizes the token, it supplies the requested data.

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

When you would request to be authenticated and the user signs in to his/her google account, before he/she grants your application permission to do stuff in their account, and if your domain has not been register with google, the user will get a nasty red box telling them to be careful because the app they are about to give access to is not registered with them.

The advantages about these methods over the old school username and password are (in my opinion) the following:

1. Enhanced security for the user: The user won't have to give you their user name and password, they have to log in to google and you will get an access token that you will use to make any further API calls. The user can revoke access to your application from inside google if they want to.
2. The process may give the user the assurance that your app is "Legit". If a user has to go through google to log in and allow your app, it may look good if your domain has been registered with google.
3. The token can be promoted to a session token: This means that you do not have to ask the user to log in every time you need to request access to the google user account, just use the session token (that you must securely save somewhere) and you are done.
4. Once you understand the process it is quite simple to authenticate users.
5. (unverified) If the user changes their password, you don't have to update the security token.
6. Lastly if you use oAuth you can create an interface that may allow you to easily authenticate users when connecting to other web services such as Vimeo!

With all of these said I guess you can figure out why it would be a bad idea to use username and passwords (which is what the ClientLogin does) to connect to a user account. Other authentication methods allow you to do the same thing (request access) and add a bunch of advantages.

The code on how to authenticate users using AuthSub can be found here, it is pretty much plug n play. just make sure to save the $_SESSION['sessionToken'] to a more permanent location such as a DB.

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

Answer 3

ClientLogin is not the preferred mechanism here because your application is forced to handle the login credentials for the user. If the user's identity needs to be established for longer than a session, you'll be forced to store the credentials and this is non ideal -- compromise of your server would lead to the compromise fo Google users. Thus ClientLogin is not the right approach for your application.

Have you looked at Google OAuth? It solves the password handling problem pretty elegantly and is an established standard.