One single solution for all OAuth integrations

During the last few months I worked with a few 3rd party vendors to establish new API integrations. These services were JSON based and secured using OAuth i.e. required that the API invocation should carry an Authorization header with previously obtained OAuth access token, obtained against a different OAuth service. Previously, I have described an idea on how to optimize OAuth token management and working on these integrations I had a chance to successfully implement it.

The implementation consisted from a gatewayscript and a configuration file. The gatewayscript core functionality is to manage the OAuth token storage, retrieval, and renewal, and also to set the stage for further business API invocation. The unfortunate issue was that I had to duplicate this implementation for each service as each invocation was slightly different. And so the new challenge was to make this piece of code universal and reusable across the board.

First, I have listed all the places that had service specific hardcoded elements. Next, I designed a solution to externalize those elements as a configuration and changed the code to support external configuration feed. There were approximately 4-5 changes that required rearchitecturing including the ability to dynamically generate headers with static and dynamic values (that's when I recalled what Java reflection is).

Long story short, the upgraded OAuth token management solution allows:

1. OAuth token management to store, retrieve, and renew access tokens;
2. Support multiple OAuth vendors and multiple APIs.
3. Dynamically generates HTTP headers for the business API invocations;
4. Support for static and runtime calculated values for HTTP headers.

The main benefit of this solution is the ease of setting up a new integration that is secured using OAuth. All that is needed - update the configuration file with the expected invocation data and incorporate the OAuth management solution gatewayscript in the processing policy. One single solution for all OAuth integrations.

How to cache an access token in DataPower

Nowadays, SOA architecture is a key basis for any successful integration. Many organizations have opened their gates to allow secure online B2B integration using Rest/SOAP APIs. Millions of transaction are executed each day. API Management solutions make the integration set up part much easier by providing potential partners controlled access to the core API reference. API performance plays crucial role and should be planned already in the design time. Cache is one of the common uses cases that could drastically improve the overall performance. This post will describe how to implement internal DataPower cache to manage and store access tokens.

For this use case let's assume we are integrating with an external partner to invoke a Business API. The API is secured and for each invocation we should provide a Bearer authorization header carrying an OAuth access token. To obtain the access token the partner provides an additional API. An example of a simple, but not necessarily optimized, API design could look like that:

Often, the OAuth access token is provided along with an expiration date, meaning it could be reused multiple times as long as it was not expired. Reusing access token is a great way to reduce network traffic and thus improve the overall runtime latency. In our design the "Obtain Access Token" snippet was adjusted to support access token storage, management, and renewal:

This could be easily achieved by using the DataPower Global Variables as these variables persist beyond the scope of request-response processing. However, keep in mind that use of global variables may introduce unexpected problems as it is not thread safe, there is always a risk of a memory leak, and if used incorrectly can cause DataPower restart.

References

IBM Knowledge Center - DataPower variables