Database Reference
In-Depth Information
One of the criticisms of the original OAuth specification is that it was too complex
for client-side developers to implement. The latest iteration of the protocol, OAuth 2.0,
simplifies the requirements to address this concern. OAuth 2.0 is gaining traction and
is being implemented to allow access to services from Facebook, Foursquare, Google,
and many others. 1
In order for our application to be authorized to use the BigQuery API, we need
to register it with Google. Service providers that offer OAuth all provide some way
to register known applications that request access to available APIs. Google provides
something called the Cloud Console, which enables teams of developers to collaborate
on projects. We will need to use the console to create two values that will allow our
application to use OAuth. The first is simply a developer project ID. We will also need
to generate a client ID, which uniquely identifies the application to Google.
Our application will also need to know the scope of data access that will be granted
by the user. In this case, we want the dashboard application to provide access only
to the BigQuery service and no other Google services (such as the Maps API or the
Google Drive API). The scope is simply a string value that identifies which service the
application may access. A scope can also limit the way the BigQuery API is used, such
as providing only read-only access to tables and projects. See the Google BigQuery
documentation ( https://developers.google.com/bigquery/ ) for more information about
available scopes.
When generating a client ID, Google needs to know where to send the user
after the authorization step. This location is called the callback URL, and for the
Google API Client Library for JavaScript, the default location for callbacks is
http://your_application_url/oauth2callback. If you are testing this sample using a
Web server on a local machine, then the callback URL will likely be something such
as http://localhost:8000/oauth2callback, depending on which port your local Web
server uses.
Once we have made all of this information available to our data dashboard appli-
cation, it will be able to initiate an OAuth user f low. When the OAuth f low begins,
your application will redirect the browser window to a Web page hosted by Google.
This Web page will identify itself as the authorization screen for the BigQuery API.
If the user is not logged in to his Google account, the page will request that the user
authenticate himself by providing a username and password. Note that this password
is for the service provider (in this case, Google) and not the application itself, so it is
not shared with the data dashboard in any way. If the user has permission to access the
BigQuery API, then he will be asked to allow the application to “view and manage
your data in Google BigQuery.” This will provide an access token to the application,
allowing it to make calls to the BigQuery API on the user's behalf. Once this permis-
sion is granted, the application will redirect the user back to the application, which is
now allowed to make calls to the BigQuery API on behalf of the user. This same f low
might be familiar to users of apps that depend on Twitter or Facebook logins.
1. http://oauth.net/2/
 
Search WWH ::




Custom Search