Database Reference
In-Depth Information
for end-user web browser authentication rather than APIs, which are often
called by programs other than browsers. OAuth and its successor OAuth2
attempt to solve the same problems as OpenID but for API access.
If you want to talk to BigQuery, you need to use OAuth2. OAuth2 satisfies
the requirements listed previously, with, of course, a cost in terms of
implementation complexity.
OAuth2
Describing the OAuth2 protocol in detail is beyond the scope of this topic;
instead, we provide the basics. If you hunger for more information, you can
Friends Don't Let Friends Re-implement
OAuth2
If you find yourself implementing the OAuth2 protocol yourself, you
should strongly consider using one of the published OAuth2 libraries
instead. They're listed on this page:
which also has helpful information about OAuth2 as it applies,
specifically, to Google APIs.
As mentioned in the last section, authentication protocols try to reduce the
number of systems you need to trust. In OAuth2, you need to trust only the
Google Authorization Server. (Yes, that's Authorization not Authentication,
sorry.) OAuth documentation tends to use the word “Authorization” instead
of “Authentication,” even though that isn't how it is used in BigQuery. One
way to think of it is that OAuth is authorizing you to access the API, and
then BigQuery authorizes you to access the resources (tables, datasets, and
so on).
Client Secrets
In Chapter 3, “Getting Started with BigQuery,” you saw how to set up a
Client ID for Installed Applications via the Google Cloud Console. If you
skipped that step, you should go read it now, because you are going to
need it here. The Client ID contains information that can identify your
