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.
