INFORMATION NOW

Some enterprise applications need to programmatically access their users’ data without any manual authorization on their part. For example, you might want to use the Tasks API to add a task to all of your employees’ Google Tasks lists during the holiday season to remind them of something like, “Come pick up your holiday gift at the front desk!” Or, you might want to run some company-wide analysis of the content of your employees’ Google Drive.

In Google Apps domains, the domain administrator can grant applications domain-wide access to its users data — this is referred as domain-wide delegation of authority. This basically allows applications to act on behalf of Google Apps domain users when using APIs.

Until recently this technique was mostly performed using 2-Legged OAuth 1.0a (2-LO). However, with the deprecation of the OAuth 1.0 protocol and the resulting programmed shutdown of 2-LO, the recommended authorization mechanism is now to use OAuth 2.0 and service accounts.

Unlike regular Google accounts that belong to an end user, service accounts are owned by your application and therefore identify your application. They can be created in the Google APIs Console and come with their own OAuth 2.0 credentials.

Google Apps domain administrators can delegate domain-wide authority to the service account’s credentials for a set of APIs. This results in allowing the application, by using the service account’s credentials, to act on behalf of the Google Apps domain’s users.

If you’d like to learn more, have a look at the recently published Google Drive SDK documentation on using OAuth 2.0 and service accounts for domain-wide delegation of authority.. These documents provide a step by step process and code samples to help you get started with service accounts.

Nicolas Garnier Google + | Twitter Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate for Google Drive and Google Apps. Nicolas is also the lead engineer for the OAuth 2.0 Playground.

Editors note: This has been cross-posted from the Google Code blog -- Ryan Boyd

In March, we announced that all of the Google Web APIs adopted support for OAuth 2.0. It is the recommended authorization mechanism when using Google Web APIs.

Today, we are announcing the OAuth 2.0 Playground, which simplifies experimentation with the OAuth 2.0 protocol and APIs that use the protocol. Trying out some requests in the OAuth 2.0 playground can help you understand how the protocol functions and make life easier when the time comes to use OAuth in your own code.

Selecting the APIs to authorize

With the OAuth 2.0 Playground, you can walk through each step of the OAuth 2.0 flow for server-side web applications: authorizing API scopes (screen shot above), exchanging authorization tokens (screen shot below), refreshing access tokens, and sending authorized requests to API endpoints. At each step, the Playground displays the full HTTP requests and responses.

Exchanging the authorization code for a refresh token and an access token

The OAuth Playground can also use custom OAuth endpoints in order to test non-Google APIs that support OAuth 2.0 draft 10.

OAuth configuration screen

You can click the link button to generate a link to a specific Playground state. This allows quick access to replay specific requests at a later time.

Generating a deep link to the playground’s current state

Please feel free to try the OAuth 2.0 Playground. We are happy to receive any feedback, bugs, or questions in the OAuth Playground forum.

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.