Lets Tutorial

Google Apps APIs are not only designed to use open web standards, but also to be very secure and reliable. In our efforts to improve security, we launched OAuth support for many of the administrative APIs last September.

Among the many benefits of OAuth is the ability to provide access to Administrative APIs without exposing admin usernames or passwords. While the Provisioning API has featured OAuth support for some time, were excited to announce that developers now have even more control over access to the API. The Provisioning API now has four separate OAuth scopes - one each for the users, alias, organization units, and groups methods. For example, this means that developers can enable an application to have access scoped to only groups and not user data. For more information about the new scopes, please see the authorization section of the Provisioning API Developers Guide.


The previous Provisioning API scope is now deprecated, and new applications should reference these new, more granular and secure scopes. While the previous scope will still work for your existing scripts during the deprecation period, it will eventually not produce valid request tokens. We strongly encourage Google Apps developers to update your applications to take advantage of this security improvement.

Provisioning isnt the only Google Apps API with recent security improvements. Were also happy to announce that developers can now authorize use of the Reporting API via OAuth! Now Google Apps developers can start building secure automated reporting and dashboard applications without worrying about managing ClientLogin tokens.

Check out this article for more information about using OAuth with the Provisioning and Reporting APIs.

Posted by Michael Manoochehri, Google Apps APIs Team

Want to weigh in on this topic? Discuss on Buzz

Since the launch of the Google Tasks API many Google Apps domain administrators have asked us how to use the API with 2-legged OAuth 1.0 (2LO) for authorization. The process for using 2LO with the Tasks API is slightly different compared to using it for the Google Calendar API or the Google Contacts APIs, which makes it a little tricky if you are already accustomed to working with those.

1. Any use of the Tasks API needs to reference a project in the APIs Console, as the Console is used to manage API quotas and other application settings (such as IP filters).
2. The Tasks API needs to be explicitly enabled for your domain OAuth key and secret.

Note: 2-legged OAuth via the method described in this post and referenced documentation is available for Google Apps for Business and Google Apps for Education administrators, but is not available for administrators of the Free edition.

Referencing an APIs Console Project

The Tasks API needs to know which APIs Console project is sending requests to the API (so quota can be deducted, filters can be checked, etc.). To supply this information, you need to specify the API Key of your project within each request to the Tasks API-- even when using 2LO. This is done by specifying the API Key in a key URL query parameter.

    e.g.: https://www.googleapis.com/tasks/v1/users/username/lists?key=<API_KEY>

The Java client library can do this for you automatically if you specify it after initializing the Tasks service:

// Initializing the Tasks API service
Tasks service = new Tasks("2-LO Tasks Test", httpTransport, jsonFactory);
service.accessKey = API_KEY;

Enabling the Tasks API for your domain OAuth key and secret

Also, before your API requests will be successful, you will need to change a few things in your OAuth Consumer Key and Secret configuration. In the Manage OAuth domain key page available in the Google Apps Control Panel (under advanced tools), you will need to make sure that the option Enable this consumer key is checked and the option saying Allow access to all APIs is unchecked. This may sound counterintuitive, but this option will give you access to a specific set of APIs and is necessary to access the Tasks API.

Setting up the domain OAuth consumer key and secret
Then you will need to specify which APIs you want your domain OAuth key and secret to have access to. You will be able to do this in the Manage third party OAuth Client access page where you will need to list manually all the scopes that your domain key will have access to. For example for your token to have access to the Google Calendar API and the Google Tasks API use:
    e.g.: https://www.google.com/calendar/feeds/, https://www.googleapis.com/auth/tasks

You should then be all set to use 2LO with your Google Apps domain key and secret.

For a more detailed and step-by-step explanation with code samples on how to use 2LO if you are a Google Apps domain admin, I invite you to have a look at the newly published article: Using 2-Legged OAuth with Google Tasks API for Google Apps domain administrators.

Nicolas Garnier profile | twitter | events Nicolas joined Google’s Developer Relations in 2008. Since then hes worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Want to weigh in on this topic? Discuss on Buzz