Making CollabSpot Boards available to Gmail users via Auth
CollabSpot Boards (CS Boards) is project management tool integrated with Google Apps. It was first offered only to Google Apps users. But months after the launch, it was also made available to Gmail users. In principle, opening the service to Gmail users wasn’t supposed to be difficult since it was already available for Google Apps users. But for someone like me who did not know much about OAuth, authorization, and authentication, things can get quite complicated. This post aims to introduce some of the terms and different ways for applications such as CS Boards to gain access to a user’s Google Account and possibly to get some feedback in those places that can still be improved.
Auth: authentication and authorization
The CS Boards back-end is written in Python and runs on the Google App Engine platform. It has the concept of cards that represent tasks in a project. Each card can have a due date set to them and CS Boards will automatically create Google Calendar event entry for all members assigned to that particular card. This is one of the examples of how CS Boards integrates with Google Apps.
This kind of access control demonstrated above, i.e. managing user’s calendar data, requires authorization and authentication. Authentication services allow users to sign in to an application using a Google Account, while authorization lets users provide an application with access to the data they have stored in Google Apps. Collectively, authorization and authentication services are often referred as Auth.
Google provides a number of Auth mechanisms:
- OAuth 2.0 is a new and simplified authorization protocol for all Google APIs. OAuth 2.0 relies on SSL for security instead of requiring your application to do cryptographic signing directly. This protocol allows your application to request access to data associated with a user’s Google Account.
- OAuth 1.0 requires cryptographic signing on Auth transactions. It provides authorization for all Google APIs.
- Hybrid protocol provides both authentication and authorization for web applications, allowing users to log in and authorize access to their data in a single step. This protocol uses OpenID to provide authentication services, and OAuth to provide authorization to Google APIs.
- OpenID authenticates users with their Google Accounts. This allows users to log in to your website without having to sign up for a new account.
- AuthSub and ClientLogin – Google’s proprietary authorization APIs, available as an alternative to OAuth for most Google APIs.
CS Boards is using OAuth 1.0 2-legged protocol and GData-Python-Client library for Google Apps users (Installed Applications).
Google Data API vs. Google API
API Client libraries provide methods to help developers implement Auth mechanisms and data access (CRUD) simpler. I knew from the start that there are Google APIs for each of their applications, Google Calendar API, Contacts API, and the Drive API. All of these have detailed documentations on how developers can use them. I also knew that each API has older versions. What I didn’t know is that the latest versions of these APIs use different client libraries than the older ones. Different, not in terms of a newer version derived from older versions, but having a totally different library architecture.
These are GData-Python-Client and Google-API-Python-Client. The Google Calendar API, for example, already has three versions. Version 3.0, the latest among them, uses the Google API Client while the older ones use the Google Data Client.
The main differences between the two:
- Google-API-Python-Client – for CalendarAPI v3, uses JSON data objects for CRUD methods and OAuth 2.0 for Auth.
- GData-Python-Client – for CalendarAPI v1-2, uses GData Protocol and OAuth 1.0 for Auth. It has two main modules: GDClient and GDataService.
OAuth 1.0’s 2-legged and 3-legged flows
CS Boards uses the OAuth 1.0 Auth mechanism. There are two ways to do OAuth 1.0: 2-legged and 3-legged. The main difference between the two is that 2-legged allows domain-wide delegation of authority and is done only by the domain administrator during app installation. As for 3-legged, also known as the normal authorization flow, it is done per Gmail user where every authorization results to an ACCESS TOKEN which the application can save to the database for future and offline use.
OAuth 2.0 is the latest, simpler, and more convenient way of doing authorizations. It relies on SSL for security instead of requiring your application to do cryptographic signing directly as in OAuth 1.0. But at the time of writing, OAuth 2.0 still does not provide domain-wide authorizations which are needed for Google Apps users and installed applications. We ultimately chose to stick with OAuth 1.0 for now with CS Boards to ensure consistency of doing things both for Google Apps and Gmail users.
Integrating Applications with Google Services provided endless possibilities, we just have used Calendar, Drive, Contacts, and Mail. Yet there is still a long list of APIs that we can integrate with. We’re currently entertaining the idea of integrating CS Boards with Google Hangouts so users can manage their projects while having a live discussion. If you are both a heavy CS Boards user and a heavy Google Apps user, let us know of any ideas you might have to make your project management experience better.