Google API: The cool way to Login Part 1

I've become addicted to Google. The company does some truly wonderful things. Not perfect by any means, but wonderful. Lately I have been playing around quite a bit with the Google calendar API and the Google spreadsheet API. Also...logging into the API, which is important to understand. I've written a few CFCs to access all this available data. It was all kind of a pain in the ass, so I'm going to review my thought process and code for how it all works on our blog. I'll do it in small bite size chunks because some of it is wonderful, but just not perfect.

The webservice API has a centralized process for authenticating. But I'll say this... it's a bit complex. For the calendar there are 3 ways to login to the API.

1) Authsub Proxy
2) ClientLogin with username/password
3) MagicCookie

The magic cookie is where I started. Basically you login to your own calendar dig around in the manage calendars area, make a calendar public, get the magic cookie and then you can use CF to access the calendar data.

But... then I started thinking. This process is lame! To make use of this in a multi user environment I'd have to create a video about what links to click in the calendar UI. Then I'd have to setup a phone bank in India just to answer questions because someone clicked the wrong thing. That's no good.

So, then the next thing I tried was the ClientLogin process. This one feels natural. Basically you pass in a username and password via a web service and it returns a token (it's a little more complex than that). Then you pass that token around with each additional web service request.

But... then I started thinking. This is all well and good for my own Google account, but no educated web user is going to type in their Google username and password into someone else's application. I might as well ask them to use their social security number as a username!

So, I tried the last method of logging in. It's the Authsub proxy. It's wierd and a bit complex, but it's the solid solution for multi-user applications using the Google API. The details of making it work take a bit of explanation. In a nutshell the way it works like this:

1) You redirect a user to a Google.com page
2) They login to Google.com
3) They click a single button to authorize your website to use a specific part of the API (like the Calendar)
4) Then Google sends the user back to your application with an "authToken"

That's the way the documentation explains it at least. But, there are 2 more steps that aren't very clear. I'll show you with some code in another post.

5) Then you make ANOTHER request for a "subSessionAuthToken" (this is the token you REALLY want, it'll make sense when I explain it)
6) Wait wait... then you make ANOTHER request for a "gSessionId" (honestly... i think this is a bug)

Even though this seems like a complex process, for you the developer, it's quite simple for your users. Of the 3 methods, the AuthSub is the most powerful approach to authenticating into an API. Because your users don't have to give you their username and password for one. Secondly, if your users want you to stop accessing their Google data, they can login to Google and revoke your token. Lastly, you can store the token in your database and automatically authenticate them into the Google API from your application in the future.

The Google documentation explaining this is, well, fair at best. They have no ColdFusion examples which doesn't surprise me. After I do more posts with the CF code, I figure I'll send my code to Google to add to their docs. The Google API is wonderful, once you get it to work.

-Steve Nelson