OAuth 2.0 for native applications

Following our previous post on OAuth 2.0 for web applications, we are now taking a look at how to use the OAuth 2.0 authentication protocol for native applications, presenting examples for the languages that we are supporting at the moment of writing: Java and Python.
Background

We strongly recommend reading Using OAuth 2.0 to Access Google APIs to learn about the Google implementations of OAuth 2.0 before proceeding with this post.
Java

The Google APIs Client Library for Java features a powerful and easy to use OAuth 2.0 library. We can take advantage of the existing GoogleOAuth2ThreeLeggedFlow helper class to easily perform our authentication flow.

First create an instance of GoogleOAuth2ThreeLeggedFlow, passing the following parameters to the constructor:

  • a key that will be used to associate this flow object with an end user
  • the Client ID for your application
  • the Client Secret for your application
  • the scope you are requesting access to (AdSense in your case)
  • the URI to redirect to
GoogleOAuth2ThreeLeggedFlow authFlow = new GoogleOAuth2ThreeLeggedFlow(
  userId, 
  "INSERT_CLIENT_ID_HERE", 
  "INSERT_CLIENT_SECRET_HERE", 
  "https://www.googleapis.com/auth/adsense", 
  "urn:ietf:wg:oauth:2.0:oob");

For native applications, we use a special redirect URI:

"urn:ietf:wg:oauth:2.0:oob"

The “oob” part stands for “out of band” and the rest of the string identifies it as a part of the OAuth 2.0 standard.

When we use this redirect URI, instead of redirecting the user’s browser to a page on our site with an authorization code, Google will display a page and the authorization code or error response in the title of the page. A text field contained in the page will show instructions for the user to copy and paste it into our application.

To start the flow, let’s ask the user to load the authorization URL in their browser:

System.out.println(“Please input authorization code: ”);
Scanner in = new Scanner(System.in);
String authorizationCode = in.nextLine();

The last step is to use the authorization code to obtain an access token.

First you’ll need to initialize a transport for communication with the Authorization server and a factory for handling JSON, as the access token will be returned as a JSON object:

JsonFactory factory = new JacksonFactory();
HttpTransport transport = new NetHttpTransport();
authFlow.setHttpTransport(transport);
authFlow.setJsonFactory(factory);

Now you can finalize the authentication flow by obtaining credentials for your user, and then use those credentials to create the Adsense helper object and then send your signed requests to the API:

Credential credential = authFlow.complete(authorizationCode);
Adsense adsense = new Adsense(transport, credential, factory);
AdClients adClients = adsense.adclients.list().execute();

Python

The home of the Google APIs Client Library for Python is also the home of OAuth2Client, a library designed for connecting to resources protected by OAuth 2.0.

First create an OAuth2WebServerFlow object, passing the following parameters to the constructor:

  • the Client ID for your application
  • the Client Secret for your application
  • the scope you are requesting access to (AdSense in your case)
  • an HTTP User-Agent to identify this application
flow = OAuth2WebServerFlow(
  client_id='INSERT_CLIENT_ID_HERE',
  client_secret='INSERT_CLIENT_SECRET_HERE',
  scope='https://www.googleapis.com/auth/adsense',
  user_agent='your-beautiful-python-app/1.0')

We can perform the authentication calling the ‘run’ function imported from oauth2client.tools, storing the authentication data using a Storage object:

storage = Storage(‘adsense.dat’);
credentials = run(flow, storage);

If the flag ‘auth_local_webserver’ is raised (the default setting), oauth2client.tools will open the authentication URL on a running browser or on the system default browser. After the user performs the authentication, the authorization code will be read from the title of the page shown in the browser. If you don’t want this behaviour, you can disable it like this:

import gflags
gflags.FLAGS.auth_local_webserver = False

In this way we’ll have a flow similar to the one that we have seen in Java: the user will be asked to open the authentication URL in a browser window and then to copy and paste the authorization code back in the application. The only difference is that oauth2client.tools will take care of printing these messages and read the input from the user for us.

The last step is create an httplib2.Http object, authorize it with the previously obtained credentials and then send a request to the API:

http = httplib2.Http()
http = credentials.authorize(http)
service = build(‘adsense’, ‘v1’, http=http)
result = service.adclients().list().execute()

Cool! But I want to know more!

In this post we have seen examples of how to authenticate your native application using the Google implementation of the OAuth 2.0 protocol and the libraries that we are providing to simplify all of the tasks involved.

Now that we know how to perform authentication for both web and native applications, in my next post we are going to see different ways of storing the authentication data.

Bing Maps: “The Hurricane Season”

 

The term ‘hurricane season’ recently brought new meaning to many communities across the U.S. East Coast in the wake of Hurricane Irene.  Being able to see the latest developments and impacted locations online through Bing Maps makes it possible to better anticipate, respond and recover from the destruction of hurricanes.

Around the world, people use Microsoft technology every day to stay in touch during difficult times. Today, we’re calling out a Bing Maps app launched by the Wall Street Journal that tracks hurricanes in the Atlantic Ocean. Tech geek or not, you have to admit this is a useful app, especially now during hurricane season. Let’s take a closer look.

 

The app is an interactive graphic that charts both current hurricanes as they are happening, and chronicles previous hurricanes dating back to 2005. So if you’ve always wanted to be a weatherman, you can bookmark the link and visit it often to see the latest weather patterns – hurricane season or not. The app is easy to use, so no meteorology degree is required.

To watch a current storm’s path, you can follow it from the moment your browser opens to the app. The storms strength is categorized on the right hand side of the screen so you can see the severity of the storm and the route it is predicted to take.  Here, we see an example of a storm pattern that started near the Bahamas as a tropical storm and as it grew stronger it became a Category 5 making its way up through the Gulf of Mexico. As it got closer to the Gulf Coast it became less intense, still remaining a Category 3 and then tapering off back to a tropical storm status.

 

To see a past hurricane, just click on one of the blue lines and it will take you to the storm’s history and the calendar at the top will move to the month it happened.

 

 

 

With Bing Maps, it’s easy to zoom in and out by scrolling your mouse so you can zoom in to see high-levels of detail or zoom out to see the past patterns of multiple hurricanes in the Atlantic.

 

 

For you self-proclaimed geeks, here’s more on how the app was built and all the things it can do:

Bing Maps’ partner, OnTerra built the hurricane tracker working closely with the Wall Street Journal team. It was created using the Bing Maps AJAX7 API, JQuery and JavaScript. It gets data from NOAA which is processed into JSON data files and refreshed every few hours, which includes the hurricane path, predicted path and the cone of uncertainty polygons. The application works great on modern web browsers including iPhone, iPAD, Android and Blackberry devices, unlike Flash and Silverlight applications. The HTML5 support in the AJAX7 API provides solid mobile device integration for interactive mapping apps like the Wall Street Journal Hurricane Tracker.

The Pictarine: Building a mashup in the cloud with Google App Engine

 

Pictarine is a photo management web application, launched in 2010, that allows people to easily manage and share all of their photos from Flickr, Picasa, Facebook, Twitter and other sites. Pictarine developers Guillaume Martin and Maxime Rafalimanana have contributed the following post discussing their experiences using Google App Engine and Google Web Toolkit.

From the start, we used Google technologies in developing Pictarine and we wanted to share our experience with them so far. In this post, we will shed some light on the weaknesses and strengths we found in Google Web Toolkit (GWT) and Google App Engine. We will also discuss how we leveraged GWT to build a new technology that allows Pictarine to seamlessly display photos from the computer directly into the browser. The following diagram is an overview of how our application works.

Building a mashup in the cloud with Google App Engine

The Pictarine team is made of a web designer and two developers who previously worked mainly with Java based enterprise technologies and had a little experience with web technologies. When we started the project in early 2009, we were quite open on learning new languages like Python or Ruby, but when App Engine announced that Java would be supported, we were really excited to give Google App Engine a try.

The first few months, learning about the App Engine environment was quite easy and dare I say fun. Testing our code on Google’s servers from Eclipse IDE was only one click away. So we built our first prototype fast and we quickly decided to adopt App Engine. Then we started to build the core of our application: the engine that uses the API from Flickr, Picasa, Facebook to fetch the users’ photos. This is where we hit the first limitations of App Engine. Most users have a lot of photos on these services and retrieving them can take some time. But App Engine has strict limits on how long a request should last: an outgoing HTTP request cannot last more than 10 seconds and cannot process a request for more than 30 seconds. So while building our architecture we found ourselves writing approximately one third of our code dealing with these limitations: paginating our requests, creating background tasks to store data in small batches, etc.

In early 2010, when we launched our alpha version, everything went smoothly. We had some good press coverage and App Engine met our expectations in handling our first users. During 2010, we worked on implementing new features requested by our users, and during this period of time we were really impressed by the way App Engine evolved. Many of the limitations were lifted and great new features were added. We are now able to use Task Queues for requests that last up to 10 minutes, which we fully use to sync our users’ photos and albums. One of the features we like the most is the Channel API, a push notification system that allows us to instantly show a photo in every connected browser as soon as it is uploaded.
App Engine is still not perfect but has greatly improved and when we see its roadmap, we are quite confident it will continue to improve.