OpenID + OAuth

Jeff Morgan

What are OpenID and OAuth
Authentication and authorization are commonly grouped together in the same conversation. OpenID and OAuth again are grouped together as they represent authentication and authorization respectively. While both OpenID and OAuth have been available as options to Google developers for a while, they now take on more significance with the introduction of Google Apps Marketplace. In fact, it is a requirement to use these two standards when integrating a web application with the Google Apps Marketplace.

OpenID
OpenID is an emerging standard that provides authentication between a provider and a relying party (typically a web application.) In the context of Google Apps it allows a web application to use Google as the authentication provider. This federated authentication approach is commonly used to provide Single Sign-On (SSO) to another web application. The beautiful part of SSO is once a user has authenticated in their Google Apps domain access to any third-party Marketplace application in their domain is transparent.

OAuth
There are two flavors of OAuth, two-legged and three-legged OAuth. While both are available for use by many Google Data APIs there are important differences that must be understood in order to know the best time to use each. Two-legged OAuth authorizes domain wide access to Google Apps domain user data at an administrator level. Three-legged OAuth authorizes access to only one user’s data by that user. In general, if you understand these main differences then making the decision to which OAuth option to use becomes easier. The Google Apps Marketplace supports two-legged OAuth since it makes sense to authorize access at the domain level by the administrator. Marketplace applications are available to all Google Apps domain users, no need for each user to grant authorization.

OpenID+OAuth
Bringing them both together is now also supported by Google. Sometimes referred to as the Hybrid Protocol, OpenID has been extended to support OAuth. While this may be useful in certain situations, this approach is now less relevant in the Google Apps Marketplace. The Marketplace manifest configuration file supports two-legged OAuth making the need to obtain an OAuth token during the OpenID process unnecessary. It is also important to understand this distinction when writing Marketplace applications because OpenID and OAuth are often grouped together, not just because of the hybrid option but because they by themselves play an important role in developing application on the Google Apps platform.

Learn More

Google IO Session
OpenID-based single sign on and OAuth data access for Google Apps

Resource Links
Implementing OAuth with Federated Login
OAuth Support in Google's Federated Login API

Give Us a Tip, Win a Book

In honor of Google I/O this week, our Google Center of Excellence (COE) team got together to lay out a few tips for using and extending the Google platform. These are tried and true techniques learned from dozens of successful Google enterprise implementations that we thought could make enterprise developers' lives just a little bit easier. Hopefully you've been reading some of our posts this week, and enjoyed them so far.

Now it's your turn. There are thousands of developers out there who have been using cloud technology from leaders like Google, Salesforce.com, Amazon and others to do cool new things, or just to do traditional things in a much better way, and we want to hear from you. What are some of the tricks and tips you've learned along the way that could help others?

To encourage sharing, we're giving away four books from three Appirio authors.

• Beginning Java Google App Engine, by Kyle Roche and Jeff Douglas (a $30 value): This book offers a Java approach to beginning Google App Engine, a key technologies to help developers build scalable web applications even with limited previous experience.
• Development with the Force.com Platform, by Jason Ouellette (a $40 value): This book explores how enterprise developers can build and deploy powerful apps more rapidly than traditional J2EE, Microsoft .NET or LAMP technology stacks permit.

Simply comment on this blog with your tip or (if you're feeling concise) tweet one to @appirio using #AppirioDevTips. We'll choose four winners from these and send you the book!

Is It Bigger Than A Breadbox?

Dan Arrigan

Just as web designers started rejoicing in the increased standard-resolutions, wider monitors and the wonderful flexibility that comes with greater available screen real-estate, along come Google Sidebar Gadgets - devices with phenomenal cosmic power, but an itty-bitty living space.

Google Calendar and Gmail Sidebar Gadgets provide an incredible access point into your Google App. Whether they are simply extending existing functionality with additional visualizations, augmenting the Apps with custom controls, or even integrating the App with additional applications - Google or otherwise - Gadgets have certainly proven themselves Enterprise ready.

As demand for powerful Gadgets rises, a new model for web design need to be embraced.

At its core, a Gadget is simply a web page; a really tiny web page. The expectations for a Gadget is to increase the value of the App; make using the app easier, make integrating with other apps smoother, generally make life better. That can be a tall order for such a small device.

The width of the sidebar is less than 170 pixels. The height of the Gadget, though technically flexible, is also limited by practicality. If you're building sidebar Gadgets, remember that your Gadget is likely one of many. In addition to planning for limited width, keep in mind a limited height that will not overly monopolize the sidebar, pushing other Gadgets out of sight. Otherwise, at the least, your Gadget runs the risk of always being toggled closed (which might be acceptable). At the worst your Gadget starts off with a negative user-reaction which might kill its chances to show its greatness; only Gadget that are evidently useful will remain in the prime real-estate of the Sidebar.

Also note that currently you have no control currently where the Gadget sits in order in the sidebar. If the Gadget is huge it heightens the likelihood that functionality will be scrolled below useful, displayed content. And though the vertical area of a Sidebar is conceptually limitless, out-of-sight is out-of-mind (which is a short step to being out-of-the-Sidebar).

So you want to keep your Gadget's height fairly limited, and your width is already fairly limited. With such constraints, how are you suppose to build anything useful?

Well, another way to think about designing for Sidebar Gadgets is to design for a cell phone's screen.

That’s right. Take your Google Android and hold it up to your monitor. Remarkable how similar in sizes the Sidebar is to the screen size. Take guidance from the height of the cell phone screen. Some incredibly powerful apps have been built for cell phones. The trick? Reusing real-estate. Instead of the vertical scrolling you’d have with Twitter’s “more” button, try pagination. Swapping out content for more content is the trick with Gadgets.

Google Sidebar Gadgets can contain as much as Inspector Gadget’s hat. But, like the hat, they need to be well organized and hidden away until they are needed.

Do you like using light-boxes for popups? Who doesn’t? Well, try that in a Gadget and you’ll have an incredibly amusing miniature box within the Gadget’s frame. The Gadget is contained in an iframe on a different domain. Unless Google has opened up access, you’re not doing much to the parent frame.

So what do you do if you really need to display large amounts of data? Links that open up new windows? Full page redirects?

Those are options. But if you’re really in a position where you need to display within the App significantly more details than can be contained within the Gadget’s Sidebar space, you always have the Canvas View option. Toggling
this View within the Gadget will take over the visible space designated for the Canvas. In Calendars this the entire width of the page (with just a little border around the Canvas). In Gmail, the Canvas view is the area that would normally display your emails.

Google Sidebar Gadgets might be limited in width and height, but they have limitless depth.

Google App Engine - Don't write in isolation

Mauricio Desiderio

With Google I/O kicking off in San Francisco this week, Appirio will be sharing tips we've gathered while developing for the enterprise on the Google platform. This post is the first of that series.

The Java App Engine SDK provides a fantastic local environment that runs your applications simulating all the services the cloud environment has. This local environment can be of great value to developers and can significantly reduce the time to market of your applications, some of the highlights are:

• Very easy to set up and use, you don't even have to configure the database!
• Provides full debugging capabilities, including breakpoints, watches, stacktrace, etc., fully integrated with the Eclipse IDE.
• Deploys are virtually instantaneous. Deploys to the cloud environment take some time, and developers want to run their applications quickly to do some functional test and confirm the behavior implemented.
• Deploys to the cloud environment may impact other users and developers, and it is a good practice to make sure that what you deploy passes some preliminary test in an environment that does not affect others before deploying.
• Some activities like loading test data is much easier and faster when done locally.
• Access to the logs in the production environment is great, but they require using a web browser. When running locally, logs are in your development tool console and local files, therefore you can use your favorite log analysis tools to find and filter things to help understand what is going on inside the application.

With all this power and ease of use it is easy to get carried away. It is very important to keep in mind that the local environment is NOT the cloud App Engine environment. If a developer does not understand the differences between these he or she could very easily create an application that works locally but not in production.

And why is that? Well, let me give some examples:

• Production a multi-tenant environment and it imposes restrictions on applications so they don't monopolize the resources that are shared with thousands of other applications. Google calls these restrictions quotas (for more information on App Engine quotas go to: http://code.google.com/appengine/docs/quotas.html). The local environment does not enforce those quotas. For example, if you create a URL fetcher that downloads more than 1 mb of data from a web source it will work locally, but fail on the cloud environment.
• Requests to your applications are not handled by a single server, but by a cloud of servers. For instance, if a static field is initialized in a request, on subsequent requests there is no guarantee that it won't be null because the request can go to a different server and run in a brand new virtual machine.
• Production App Engine requires indexes to perform database queries (for information on queries and indexes go to: http://code.google.com/appengine/docs/java/datastore/queriesandindexes.html), if an index does not exist, or it is not in a "Serving" state (i.e. it is a new index that is being built) the query will fail. The local environment by default creates missing indexes transparently for you.

My suggestion is to study and understand the differences between the two environments and implement code that takes those into consideration. Use the local environment specifically for development. Do all your unit testing, test your functionality, and do your debugging locally but never assume a feature is ready to release until you deploy and test it on the cloud environment.