Developers who work with accessing APIs are probably already largely familiar with the paradigm that OAuth works under: it’s an identity and authentication API. In his session, Adam Eijdenberg describes how to connect your applications with Google’s services using OAuth from how to produce keys for applications to use the API, how to implement them in code, and what that means for developers.

Below is a video of the OAuth session from Google I/O 2013 with Eijdenberg and Ben Wiley Sittler–but here’s what most developers might take away from this session.

There are two ways that OAuth is normally used by developers: first, to allow an application to access Google as proxy for a user (say to access a user’s Google Drive to read or store information in a document) such as for user-based configuration persistence across devices; and second, to allow a particular application to access Google services as part of business intelligence (irrespective of user, since some applications have no users or are user agnostic.)

OAuth allows both of these particular cases to easily be implemented but in most cases, the latter case is more common than the former. This is especially the case when it comes to accessing cloud-based Google infrastructure such as activating data analysis from BigQuery, or crunching in Compute Engine, or any other service that an application might want to gather information from. Many developers may be writing an application that runs as a back-end for a website or a mobile app that controls its own users, but needs to access and provision its cloud infrastructure (database and compute) that it then collates itself.

How OAuth works directly in code

Ben Wiley Sittler takes the stage around 17:00 and goes into the nitty-gritty nuts-and-bolts part of how to use OAuth in code to access and control Google services—in his case he starts with a BigQuery function. For those developer geeks out there interested in how OAuth functions in code (in this cause using JSON as the web API) this is a good section to watch.

Google hosted environments and security

OAuth acts via access tokens to grab onto cloud-infrastructure such as App Engine and Compute Engine.

After an application grabs an authentication token from OAuth, it can use that token to prove that it’s who it says it is when provisioning application space or compute space from these Google services. Those tokens having already been controlled by configuring a public-private key for the application, access control lists/rules, and thus know how to identify the application. All that’s needed is one access token to access any given API (since all the Google services operate from the same infrastructure.)

When using Google’s services via API access tokens are automatically refreshed when they’re about to expire and should the token be lost while the authenticated client is still connected a new token is sent. Of course, tokens can be deauthorized via the API or after an hour of no activity the token will no longer function and will not be refreshed (unless a special “refresh token” is used to grab a new authorization token.)

All communication with OAuth is heavily encrypted using SSL—as most of the API is web based—and as long as that is in place it would be very difficult for the token or even the connection to be intercepted by an attacker. Fortunately for almost all developers numerous data security layers already exist in every library that will work with OAuth and Google’s cloud services.

Once a developer has authentication with OAuth understood and is capable of doing it via the API library they’re using it will work essentially the same way with every other Google service. Even when multiple Google services are being used (App Engine and Compute) all of them can use the same OAuth token for the same application and will be aware that they’re all talking to the same application through the token.