Building a Data Dashboard with Google BigQuery - Data Just Right: Introduction to Large-Scale Data and Analytics - page 76

choice for building or integrating into existing data dashboards. Because there is no
infrastructure to manage, developers can focus primarily on building client-side tools.
To illustrate the process of using a browser-based client to connect to the BigQuery
API, we will use JavaScript along with some helpful libraries. The Google API Cli-
ent Library for JavaScript provides methods for making calls to the BigQuery API and
some helper methods for authorizing access to BigQuery. Our simple application does
three things: asks the user to authorize access to the BigQuery API, runs a query, and
returns the results to a browser in order to display a visualization.
Authorizing Access to the BigQuery API
The BigQuery API is a Web-based service; it is accessed via an HTTP request that
makes a call to a URL available on the public Internet. Web services need to have
both fine-grained permissions and a mechanism to ensure proper authorization of their
use. BigQuery supports a variety of sharing options for each dataset. A dataset may be
made available to a single user or a group of users, or even made public to anyone with
access to the API. When a user tries to access our dashboard, how does the BigQuery
API know if that user has permission to access a particular table or dataset?
One solution to this problem might be to give each user a password to access the
BigQuery API. When our dashboard needs to make a call to BigQuery, the applica-
tion can ask the user to either supply the password or share an already stored password.
Unfortunately, requiring passwords is not a very secure way to provide access to Big-
Query. How do we know the application in the middle—that is, our dashboard—will
store our precious password securely? There is no way for us to guarantee the security
of what happens with our application.
When building an online application, we ideally want to allow the application to
use external APIs on a user's behalf without that user having to share the password for
that service. In this case, we want our data dashboard application to access BigQuery
without users sharing their Google account passwords. Instead, we would like to give
the application access to the user's BigQuery data for only a limited time.
Fortunately, there is a way to provide this level of access. The OAuth protocol
defines a standard for accessing network resources without having to share your user
password. Instead, a special access token is created by the service provider (in this case,
Google), and the token is scoped to allow access only to a specific network resource—
such as a user's BigQuery tables. In a typical browser-based f low, the application (in
our case, our dashboard) will make a call to the BigQuery API asking for authoriza-
tion. The BigQuery API will redirect the user to a Web page that it controls, from
which it provides a form that asks the user to authorize access to the API.
Not every application is Web-based, of course. Some applications are designed to
run on the desktop or on embedded devices or left to whir away on servers. What
if the application doesn't have access to a browser window? Apart from the browser-
based authorization f low, the OAuth protocol defines a variety of f lows to access Web
services using these other methods.