Enabling OAuth To A Google JSON API Using The Vordel API Gateway

Enabling OAuth To A Google JSON API Using The Vordel API Gateway

OAuth is a very popular way to manage access to APIs. Amongst other things, it enables users to log into an application (which could be an application on a phone or tablet) and then that application calls lightweight APIs on their behalf. From a user’s point of view, they accessed the application, and it all “just worked”. They didn’t have to enter any more passwords. From an implementation perspective, it’s more complex of course. But an API Gateway makes it simple to call lightweight APIs using OAuth.

When I say “Lightweight APIs” in the paragraph above, I mean REST Web Services which generally use JSON. And what is JSON? JSON is a lightweight alternative to XML, which is increasingly used to bypass heavyweight XML parsing (and, in some cases, to bypass the security controls of the XMLHttpRequest object often used in AJAX).

JSON and REST can be seen as more efficient optimizations of what went before. OAuth is far from being “just another authentication mechanism”. To understand OAuth involves understanding how it is used. For APIs, it generally involves an application (e.g. an Android app) accessing the API on the user’s behalf. Phil Hunt has an excellent explanation of this aspect of OAuth here:

OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner’s (e.g. the user) behalf using only HTTP to access REST based services in a lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified “scope”.

http://www.independentid.com/2011/04/oauth-does-it-authorize-yes-but-much.html

[ It's also worth following the link above to Phil Hunt's piece if you're ever wondered why the HTTP header "Authorization" is not called "Authentication"]

So, all in all, there are a lot of new technologies at play here: OAuth, JSON, APIs, and even REST. And there is also a new concept, the API Gateway. An API Gateway applies the security mechanisms such as OAuth, which is required to authenticate to an API. But, beyond this, it also provides:

  • Monitoring of the API usage
  • Alerting if the API is not responding correctly
  • An audit trail of API access
  • Validation of API content
  • Redaction and tokenization of content being sent in API calls
  • Mapping to identity stores

Putting it all together, here is a demo of how a user can authorize the Vordel API Gateway to access a JSON API with OAuth on their behalf.

In the video below, I’m using an Android tablet to authorize the Vordel API Gateway to access an API on my behalf. In the Android environment, I am already logged in with Google, and the API Gateway leverages this to ask me do I want to access the API using my Google logon. In this case the API is a Google URL-shortening API. When I authorize it, then from that point on the Vordel API Gateway is enabled to access this API on my behalf. At the API Gateway level, you can see in the video that the API usage and access is managed. The API Gateway administrator can add controls such as JSON validation, detection of private data leakage, and tokenization (replacement of private data with an opaque token). At no point does the user have to worry about creating OAuth headers – this is all taken care of at the API Gateway.

This is the first in a series of videos on the API Gateway topic – watch this space for more!