Google Data

By Greg Robbins, Software Engineer

(Editor’s note: Long-time readers know we sometimes publish posts aimed at programmers, and this is one of those. If you’re not a software developer, don’t worry. Our usual non-technical stuff will return.)

It’s rare today for any software to live in isolation. And often, applications want to connect to data in your Google Account. Social networks seek access to your Gmail contacts, finance programs try to sync with your Google Finance portfolio, and photo editing software would like to add eyeglasses and mustaches to the photos in your Picasa Web Albums account. But you probably don’t want your photo editing program to be able to download your financial portfolio, spend money with your Google Checkout account, or have access to any of your other personal data.

The fundamental problem is that giving your username and password to a program hands it access to all of your data. Recently, Internet software developers have converged on a solution called OAuth. When sites and software support OAuth, you only need to give your username and password—your credentials—to the site where your data belongs, and that site passes a token with strictly limited authorization rights back to other sites and software.

For example, if you want to use the new SuperAwesomeEditor application to trim your YouTube videos, the editing program can use OAuth to ask YouTube for permission to edit your videos, and then YouTube will ask you to verify your identify. Once you give your username and password to YouTube, it will hand back to SuperAwesomeEditor a token allowing it access just to your YouTube videos for editing. SuperAwesomeEditor won’t know your password, so it won’t be able to grab your financial documents or check out your Gmail contacts. And tomorrow, if you change your mind, you can tell YouTube to cancel that token, and suddenly SuperAwesomeEditor will be unable to access your videos at all. Now you’re in control of your personal data.

OAuth offers another big advantage: it gives the data provider flexibility in how it authenticates you. So today you may be asked for your username and password, and also to solve a captcha to prove you’re human. Tomorrow, with tighter security, the provider can add another means of authentication, perhaps by sending a text message to your phone with an extra passcode to type when signing in. Improvements in user authentication over time like this aren’t possible in software that only knows how to ask for a username and password.

Unfortunately, the rose of OAuth comes with thorns. One bit of pain is that it takes a lot of tricky programming for applications to use OAuth for authentication. Another downside stems from OAuth having been designed to allow one website to obtain authorization from another; it is not well-suited for use in installed applications, such as native iPhone, iPad, or Mac OS X software.

To encourage adoption of OAuth by Mac and iOS apps, we have released the Google Toolbox for Mac OAuth Controllers. This small set of Objective-C classes makes it easy for developers to add OAuth sign-in embedded into Cocoa apps. Since adoption of OAuth extends beyond Google, the OAuth controllers work with both Google and non-Google data providers.

Here’s how easy it is for developers to let users sign in to Google Contacts with OAuth from an iPhone application:

#import "GTMOAuthViewControllerTouch.h"

NSString *keychainItemName = @"HotSocialNetwork: Google Contacts"NSString *scope = @"http://www.google.com/m8/feeds/";  // scope for Google Contacts API

GTMOAuthViewControllerTouch *viewController = [[[GTMOAuthViewControllerTouch alloc] initWithScope:scope  language:nil  appServiceName:keychainItemName  delegate:self  finishedSelector:@selector(viewController:finishedWithAuth:error:)]     autorelease];[[self navigationController] pushViewController:controller animated:YES];

When the user finishes signing in, the controller will invoke the application’s callback method:

- (void)viewController:(GTMOAuthViewControllerTouch *)viewController  finishedWithAuth:(GTMOAuthAuthentication *)auth             error:(NSError *)error { if (error == nil) {   // Authentication succeeded; retain the auth object }}

That’s it. The controllers handle displaying an embedded web view and interacting with the server, and optionally saving the authorization token in the keychain. Later on, the application can use the auth object provided to the callback to authenticate and sign requests it makes to the server, like this:

[auth authorizeRequest:myNSURLMutableRequest];

Authenticating to non-Google services takes a few more lines of code to specify the application’s identity and the server addresses needed for authorization, but it’s almost as simple.

The OAuth protocol is in transition, as a newer version is currently being developed. But if you are a developer, there is already benefit to adopting OAuth for letting your users sign in to Google and other services. For more information about using the GTM OAuth controllers in your app, read the introduction at the project site, and join the discussion group. Google also maintains a site for our ongoing research into OAuth and related subjects.

The OAuth Controllers are an independent sibling project to the Google Toolbox for Mac, a collection of useful classes for iPhone and Mac developers. The controllers incorporate the newly-liberated GTM HTTP Fetcher project, our networking wrapper class, which I’ll discuss in an upcoming post. You can find more of our open-source Mac and iPhone toys on the Google Mac Developer Playground at http://code.google.com/mac.