The Changes to OAuth 2.0 endpoint


In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on November 15, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as After this change, it will be returned as

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:

  1. Redirect the browser to the Google OAuth 2.0 endpoint.
  2. The user will be shown a consent page.
  3. If the user consents, parse the authorization code from the query string of the response.
  4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.

Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:

  • Users will only see the consent screen on their first time through the sequence.
  • If the application requests offline access, only the first authorization code exchange results in a refresh token.

To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:

You can maintain the current behavior by changing the target URL to:

You may start including these parameters in authorization code requests today.

Google Earth: Mapping the Peachtree Road Race


The 42nd annual Peachtree Road Race, one of the largest 10K races in the world. There are expected to be 60,000 running the race this year, so it should be quite an event.



There are a variety of sites that have interactive maps of the course, and I’ve found is one of the best. Along with standard maps of the course, they also provide an elevation profile, which explains why many people run too fast during the first half of the race and burn out before the finish:


Of course, my favorite feature is simply being able to download the KML file and explore the course for myself. Atlanta has solid 3D building coverage, especially toward the end of the course:


The race is held every year on July 4th, which is Independence Day in the United States. If you’ll be celebrating the holiday today, I hope you have a great time and stay safe!

Rediscover Historical Imagery in Google Earth 6

Historical imagery is one of the most powerful features of Google Earth, enabling you to go back in time and browse the visual historical record of our planet – from the evolution and rise of developing communities to the destruction caused by hurricanes, earthquakes and fires. With Google Earth 6, we’ve made it easier than ever to discover historical imagery. In addition to streamlining the timeline interface, we’ve added a date button to the status bar to notify you of past imagery that you might be interested in exploring. So now, when you zoom in on a location in our latest version of Google Earth, the button will appear highlighting specific years. Clicking it enables historical imagery and takes you back to the year you selected. For instance, when I zoom in on the headquarters of a certain company with a fruit namesake nestled in the heart of Silicon Valley, Google Earth suggests imagery from 1948. Clicking the date button reveals the fruit tree orchards that used to inhabit that very location. I wonder if they were apple trees.
Google Earth 6 suggests historical imagery to explore, e.g. of Silicon Valley in 1948
In the almost two years that historical imagery has been available, we have captured several moments of cultural significance, such as the inauguration of the first African American President of the United States, the devastation of Hurricane Katrina, and the transformation of South Africa in preparation for the 2010 FIFA World Cup.
Washington D.C., January 20, 2009. Can you spot where the jumbotrons were installed?
But the feature is more than just what historians deem significant. We built the historical imagery database to enable anyone to see and tell their own personal history. A great example comes from fellow historical imagery engineer Reuel Nash:

The construction of Terminal D at Dallas/Fort Worth International Airport
We have a vast amount of data in our historical imagery archive, so you’ll be able to tell your own personal stories by browsing those places that are special to you. In fact, we have more square miles of high resolution imagery in our historical imagery archive than in our default view. In the coming years, we look forward to expanding this imagery collection even further. Visit the Historical Imagery Showcase to watch video tours of cities with imagery dating as far back as 1940.
Posted by Chris Co, Google Earth Software Engineer

In 1979, my wife and I spent the first night of our marriage in a hotel at Dallas/Fort Worth International Airport. It was still there in 1995, which you can see in Google Earth. The hotel and the surrounding area has since been replaced by Terminal D. You can see the terminal construction (and destruction of the hotel) literally from the ground up using historical imagery.