Google dumps keys, passwords; secures services with standards, certs

Google is improving security for Web applications connecting to its server-based platforms by dropping keys and passwords and turning to certificates and an emerging protocol called OAuth 2.0.

Google is throwing away the shared keys and passwords that developers use to access its server platforms in favor of a pioneering combination of open standards and certificates to boost security.

The search giant Wednesday unveiled Service Accounts, which provide certificate-based authentication using an emerging identity standard and a variety of access token types to secure server-to-server communication. The certificates support stronger security when web applications interact with Google services such as Cloud Storage. With certificates, the application requesting data has to validate its identity before accessing an application programming interface (API).

The certificate authentication does not require any end-user interaction.

In a blog post authored by Google product manager Justin Smith, the company said that certificates offer better security because unlike shared keys and passwords they cannot be read or guessed by humans.

Google is the first service provider to implement certificate-based authentication on the back of the emerging OAuth 2.0 protocol, which is nearing final approval as a standard at the Internet Engineering Task Force (IETF).

The flow of information to obtain and validate the certificate and its payload uses JavaScript Object Notation Web tokens (JWT), which are exchanged for OAuth 2.0 access tokens on Google's site.  JavaScript Object Notation (JSON) is a lightweight data-interchange format.

"The benefits are fewer passwords, stronger authentication, better security, interoperability, and choice of vendors," said Brian Campbell, a co-author of the IETF draft specification the outlines how a JWT token requests an OAuth 2.0 token. (Disclosure: Campbell is a senior architect for my employer - Ping Identity.)

Google's move to certificate-based authentication shows how OAuth can be integrated with PKI and existing corporate certificate tools. The design also supports asymmetrical crypto so Google never has a copy of a company's private key.

Campbell and other experts contend that Google's implementation shows that OAuth 2.0 is an enterprise-ready security standard, and given the fact it does not specify token types provides corporate IT with quicker implementations and more flexible integration options.

Google's Service Accounts capabilities are initially being added to a host of its developer services, including Google Prediction API, Google URL Shortener, Google OAuth 2.0 Authorization Server, Google APIs Console, and Google APIs Client Libraries for Python, Java, and PHP.

Google will make integration easy for developers by offering a few lines of code that can be dropped into applications. Service Accounts supports Google APIs Client Libraries for Python, Java and PHP. The company plans to add Ruby and .NET support at a later date.

Integrating authentication technologies into applications can prove tricky and expose vulnerabilities as highlighted in a recent technical paper released by Microsoft Research. The paper showed API integration based on poor code written by web site developers led to fatal security flaws in Web-based SSO.

To wit, Google is strongly advising developers not to write their own logic for creating and cryptographically signing the JWT access tokens used with the OAuth 2.0 specification. Google suggests using libraries instead.

"Writing the code that abstracts token creation and signing is prone to errors that can have a severe impact on the security of your application," Google said in its Service Accounts documentation.