Earlier this week, Google made a quiet announcement that could have a widespread impact: Web applications that integrate with the Google platform no longer use passwords or shared keys, relying instead on certificates and the OAuth 2.0 secure login standard.

To be more precise, these new Google Service Accounts are designed to both secure and simplify server-to-server interactions. That means an application that’s accessing, say, Google Cloud Storage will authenticate using the certificate, not a human-readable, guessable password, according to a blog entry by Google Product Manager Justin Smith.

Right now, Service Accounts are enabled for the following Google developer services, with the promise of more Google APIs and client libraries (including libraries for Ruby and .NET) coming over time:

• Google Cloud Storage
• Google Prediction API
• Google URL Shortener
• Google OAuth 2.0 Authorization Server
• Google APIs Console
• Google APIs Client Libraries for Python, Java, and PHP

Service Accounts are implemented as an OAuth 2.0 workflow, compliant with draft 25 of the specification. To authorize with a Service Account, the applications generates a JavaScript Object Notation (JSON) structure, signs it with a private key, and encodes it with a JSON Web Token (JWT). The JWT gets sent up to the Google OAuth 2.0 Authorization server in exchange for an access token, which in turn gets sent to the API in question.

The client libraries for Python, Java and PHP wrap all of that in a few lines of code and “abstract the error-prone signing and encoding operations from your applications,” and Smith recommends that developers use the client libraries for this kind of server-to-server interaction rather than risk human error.

As Smith notes, this functionality has been open to Google App Engine developers for some time, but this update brings OAuth 2.0 to other server-side platforms.

Services Angle

Google’s adoption of OAuth 2.0 for its cloud storage and prediction APIs is an important step forward for the OAuth protocol in general. OAuth 1.0 demonstrated the value in not having to hand out credentials to outside applications, but OAuth 2.0’s value is in developer simplicity while providing authorization flows for applications running across desktop and mobile environments.

In fact, the Facebook Graph API only supports OAuth 2.0, in the largest usage of the standard-to-be to date. But Google’s deployment could go a long way towards demonstrating the service’s enterprise readiness. As ZDNet’s John Fontana points out, Google’s asymmetrical design means an enterprise never has to expose its private key. And certificate-based authentication means that it can integrate with pre-existing corporate certification tools. Google’s move could mean a major shift towards OAuth 2.0 for web applications, which in turn means a more secure application ecosystem for developers and customers alike.