Channels ▼
RSS

Security

Getting Started with Google Apps and OAuth


Over the course of the next few months, we're going to look in depth at how to integrate Google web applications, like Calendar or Contacts, into your own web applications. If your app requires calendaring capabilities, for example, you can just use Google Calendar instead rolling your own calendar. Your app can create, read, or modify specific calendars within Google Calendar, or even access all of them if that's necessary. This mash-up approach has several advantages: Your users get a UI that's already familiar; they need to maintain only one calendar that can encompass their entire life (rather than several calendars, one for each application), and they can easily access the calendar functions from cell phone.. In the case of Google Docs integration, you can offload your document-storage issues to Google, including the physical space required to hold the documents.

There is a downside. If Google Calendar goes down, so does your application. If your users prefer iCal or Outlook, then you're in the position of reconciling different calendar applications or supporting all of them. The reconciliation process isn't too bad with calendars, all of which are pretty much the same, but it's a nightmare with Contacts.

In terms of the user experience, learning how to master a new UI is a significant barrier to adoption, so letting your customers use familiar applications to do familiar things is a very good thing. More to the point, you can probably write integration code for three separate calendars in less time than it would take to build a high quality calendering system. In fact, in the case of calendars, you can get away with implementing CalDAV (IETF RFC 4791), and integrating it with just about everybody. Unfortunately, there isn't an IETF standard that gives you access to the other Google services, so we need to know how to do things in a Google world, too.

Authentication

The one requirement that all Google services impose is authentication. Although you can access all the services with a Google username and password, most of your users will be unwilling to let you have that much access. A better approach is for your users to tell Google exactly which services they'll allow your app to touch. In fact, even finer granularity is possible — they could restrict access to a single calendar, for example. Google actually provides two mechanisms for doing that. There's an older mechanism called AuthSub, but Google has effectively deprecated that protocol in favor of OAuth — an open protocol that's not at all Google specific. (The main website for the OAuth project is OAuth.net. The Beginners Guide to OAuth is particularly helpful, and is better than the introductory documentation on Google's site.)

This month, I'll go over the OAuth protocol, noting the things you need to do to get started, and I'll also discuss several security issues. Next month, I'll present a complete example of the entire authorization process. If you're in a hurry, Google provides samples of the essential code here, but those examples are just out-of-context snippets (in Java, Python, and PHP). Also, Google's article, Using OAuth with the Google Data APIs, describes the HTTP/REST protocol that underlies the high-level-language implementations, and demonstrates how to use Google's OAuth Playground, which lets you walk through the actual process manually. Exercising the actual protocol manually will make my explanations a little easier to absorb.

Setting up Google Apps

The first thing we'll need to do is set up a Google Apps account. via the link at http://www.google.com/apps/. If you haven't explored Google Apps, you should spend a few minutes looking it over. Google Apps lets you support various Google services (like Calendar and GMail) using your own domain name rather than google.com. Even if you use if for nothing else, I'd honestly recommend that you use Google Apps for email so that you can use a real email address (me@myDomain.com) rather than a Micky-Mouse me@gmail.com address. Most small companies are better off using Apps to manage their email than doing it via an ISP — it has more useful features. For one thing, Google has, by far, the best spam filtering out there, and forwarding your email from an ISP service to GMail to do spam filtering doesn't work very well because Google will most likely decide that your domain (from which the email is forwarded) is a spammer. When you set up Google Apps for email support, you modify your DNS record so that email sent to your domain is forwarded directly to Google rather than to your ISP. (The part of the DNS record that points to your website is unaffected by this change.)

Google Apps accounts come in two flavors: free, which will work fine for the moment; and "for Business," which costs $50 per user account per year. (Think of a user account as an email in-box.) There are a few advantages to actually paying: You get 24x7 technical support, a 99.9% uptime SLA, better spam filtering than GMail, and more storage for things like email. You also get a guarantee that Google won't lose all your saved email (which has happened to friends of mine who had normal GMail accounts). The other advantage of paying for the service is that Google provides a few apps that aren't generally available. The free account provides customized-to-your-domain versions of email (GMail), Docs, Groups, Chat, Contacts, and Sites — the basic facilities that are provided to every Google account. Paid accounts add video (effectively domain-specific YouTube), Postini (which adds things like virus detection, black-list blocking, email-encryption services, and rapid failover in the event of a email-server crash), and a version of Wave (a pretty useful, though soon to be unsupported, collaborative-workflow tool that I rather like. It lets several people who aren't in the same physical location simultaneously edit a shared document while on a conference call, for example).

A Few Terms

Before moving on, I need to introduce some vocabulary; see Table 1.

[Click image to view at full size]
Table 1. Vocabulary.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video