Does your application need end user permission to access their Google data?

When developing web applications, developers are sometimes faced with deciding between AuthSub or OAuth. However, the first question should be, "Who will be granting permission to the user's Google data?" If the end users are Google Apps users then most likely it will be an administrator granting access. Frequently developers ask the same question in another way, "Should I use 3-legged or 2-legged authentication?" Ideally, from a Google Apps user experience perspective, it is better to use 2-legged OAuth. This way the application is granted access to a user's Google Apps data at the administrator level. The end user can start to use the application and the trust has already been established by an administrator. If you are developing a Marketplace application then it is very likely you will not need to engage in the 3-legged authentication dance.
However, if you are writing an application that is wide open to anyone with a Google account, let the 3-legged dance begin. Both AuthSub and OAuth for Web Applications are designed for this purpose. However, the behavior and look and feel for each is slightly different. Both ultimately allow the user to grant your application access to their data, but knowing the differences helps you make the best choice. Here is an article that covers the topic and should help you choose. It has color coded highlights that compare the two.

Some general rules follow when choosing an authentication method:

End User	Authentication
Google User (regular)	AuthSub or 3-Legged OAuth (3LO)
Googe Apps User (hosted)	2-Legged OAuth (2LO)
No end user	2LO or ClientLogin

Gadgets

Again there are different options for choosing Google Data authentication from a Gadget container. The first option to consider is OAuth Proxy for Gadgets. OAuth proxy is a 3-legged dance asking the end user for permission to access their data. Once access has been granted then the gadget developer can use the gadgets.io.makeRequest()method to make the Google Data API calls. Most likely you will want the JSON response from the feed so remember to add the ?alt=json URL parameter. For more information and code examples on OAuth Proxy see Writing OAuth Gadgets.

For Marketplace Gadgets another authentication option is available and uses OpenID. This option is used to authenticate the user and determine identity only and it does not provide authorization for API access. After the user is authenticated, server-to-server calls are used to make the requests, authorized via 2-legged OAuth and specifying the xoauth_requestor_id based on the authenticated user from OpenID. For more information on this approach see the Marketplace Best Practices page.

Secure Storage of Credentials

Adding layers of security is a common approach to to making data more secure. Google does provide various layers by providing different authentication and authorization methods. Registering web applications, supporting digital certificates, support for industry standards, (SAML, OAuth, OpenID) all help in providing security. However, one of the most common mistakes we can make is not taking care to protect important credentials. When working with Google Data ClientLogin and 2-legged OAuth, these credentials can be keys to the kingdom (e.g. administrator credentials or domain OAuth consumer secret) and therefore should be protected at all costs. Access to these credentials can potentially open the entire Google Apps domain data for the authorized services. This could have tremendous impact especially if you are maintaining 2-legged OAuth credentials for domains that have granted your application access, e.g. a Marketplace application. Therefore it is risky practice to embed them in source code or even a configuration file. Consider using an approach that allows you to enter credentials at runtime and store in memory or use your favorite method for secure storage of these important credentials.

Google Apps Marketplace

With the March announcement of the Google Apps Marketplace, the decision making process may have become a little easier. OpenID+OAuth and 2-Legged OAuth are the schemes that are supported and likely will be used if your Marketplace application needs access to Google Apps data; which is very likely. You’ll notice that the Marketplace has embraced the open standards of OpenID and OAuth. While AuthSub and ClientLogin are proprietary to Google, they will likely not be useful in your Marketplace application.

ClientLogin

If your application needs to create or make modifications to user accounts (using the Provisioning API) then your only current option is ClientLogin. But a common oversight is to not reuse the access token. Without proper reuse of this token, eventually your application will force the account into a CAPTCHA state which can easily be avoided if the access token is used for subsequent ClientLogin authentication requests. It is best to keep this token cached in memory and renew the token in some configured frequency/timeout.

Summary

This post covered some important considerations for selecting a Google Data authentication method for your application. If you are new to Google Data authentications and want to have a better overall understanding then start with the Getting Started with Account Authorization guide. No matter which approach you choose make sure that accessing users data is done is a secure user friendly way.

References

Google Data authentication is a vast topic. For your convenience here are a list of resources.

Expensify does expense reports that don't suck by importing expenses and receipts from your credit cards and mobile phones, submitting expense reports through email, and reimbursing online with QuickBooks and direct deposit.

The Foundation: Single Sign-On

We were really excited when Google approached us to be a launch partner for their new Google Apps Marketplace because tons of our customers use Google Apps -- including us! We have long wanted to put an 'Expenses' link up there next to Mail and Documents, and now we had our chance.

To do that, we installed the JanRain PHP OpenID library with the Google Apps Discovery extension. We’d already implemented Gmail OpenID and ironed out the kinks related to having multiple logins to a single account, so implementing this was a very straightforward process.

Lessons Learned

We quickly learned that while single sign-on is awesome, there was a high drop-off rate among admins installing Expensify into their domain. Digging deeper we determined it was due to the setup process being split: part of the setup was done from within Google Apps, but the final part had to be completed by signing in to our site. Not only that, a major part of the setup process was laboriously entering their employee’s emails. We decided to address each in turn by creating a setup wizard and importing the domain’s email list. We approached this change in two major ways:

First, when the Google Apps admin installs the Expensify application, we created a custom configuration step that creates what we call an 'expense policy'. This governs everything from who is part of the company, who can approve expenses, and ultimately who exports to QuickBooks to keep the general ledger in check. Previously this step had to be done after the application was already installed, usually when the admin first signed in. By making this step part of the install process, the entire setup felt much more intuitive and resulted in a higher completion rate.

Second, we used the Zend framework to connect to the Google Apps Provisioning API to fill the new expense policy with a list of all existing employees. This saved a ton of typing and resulted in a vast reduction in the time it took to deploy Expensify to the full company. With everything else in place, the code we used to do this looked something like this:

$oauthOptions = array(
     'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER,
     'version' => '1.0',
     'signatureMethod' => 'HMAC-SHA1',
     'consumerKey' => $CONSUMER_KEY,
     'consumerSecret' => $CONSUMER_SECRET
 );
 $consumer = new Zend_Oauth_Consumer($oauthOptions);
 $token = new Zend_Oauth_Token_Access();
 $httpClient = $token->getHttpClient($oauthOptions);
 $service = new Zend_Gdata_Gapps($httpClient, $domain );
 $users = $service->retrieveAllUsers();

All of the users’ names and emails are presented in a table of employees that the person installing the app can use to set roles and quickly build an approval tree for all expenses.


Once the setup is completed, we automatically create accounts for all of the selected employees and send out a brief email with tips to get started.

Results: 3.5x more users sign up

Overall it was a fast and painless process, has increased the flow of high-quality leads, and has accelerated their rate of converting into real users. Domain admins now sign up 3.5x more users right away than they have been using the previous two-part setup! Feel free to install our app to see how the setup process works, and respond to this post with questions about your implementation -- we'll try to help out as best we can. And of course if you're still doing your expense reports the old sucky way, please come visit our website (Expensify.com) and we'd be happy to help ease your pain. Thanks for reading, let me know if there's anything I can help clarify!

Posted by Zhenya Grinshteyn, Expensify

Want to weigh in on this topic? Discuss on Buzz

Harvest

"So many actions and todos originate from emails. Today, with contextual gadgets, we deliver the user their timesheet so it's incredibly convenient for them to fill out."
- Danny Wen, Harvest Co-founder.



Head over to the Google Enterprise Blog if you want more detail on these applications.

Contextual Gadgets greatly accelerate user adoption by bringing the application directly to the user in context and in their normal work flow. Many great apps fail to gain user traction because they are separated from the normal workflow. Gmail Contextual Gadgets solve that problem for developers, and make it much easier for the end users to see the benefits.

If you think you’re ready to start saving time for the users of your application, then dive right into the Developer’s Guide for Gmail Contextual Gadgets. Since gadgets are based on the OpenSocial gadget specification, they’re developed in the technologies you’re already familiar with -- HTML, JavaScript and CSS. Get started now, and be sure to share what you build!

Posted by Ryan Boyd, Google Apps Marketplace Team

Want to weigh in on this topic? Discuss on Buzz