Beyond OAuth – Emerging standards for API access control

April 10, 2012

OAuth 2.0 seems to be on everybody’s mind these days. I can’t remember an emerging standard picking up interest so fast. The Layer 7 OAuth toolkit evolved through three stages over the last couple years and I’m proud to say that I was involved right from the beginning. It was first developed out of necessity using existing elements of the Layer 7 Gateway solution – a testament to the flexibility of the platform. Then, leveraging precious feedback from numerous architects applying OAuth with our gateway, the OTK matured, became a product of its own. Today, we’re witnessing the 3rd evolution phase: OAuth is making its way to the very core of the Layer 7 Gateway platform.

I mention these different evolution phases because I noticed how different engineers working at these different levels, and in some cases isolated from each other (I travel a lot), identified very similar patterns relating to implementing API access control using OAuth. I’m talking about interaction patterns between various components involved including for example a token issuer, an api consumer, a policy enforcement point, etc. These parties need to discover information at runtime relating to tokens and identities, tokens need to be stored somewhere and managed. It just seems logical that this information would be exchanged via open APIs themselves. Integrating these logical components via APIs means that you can easily separate them as needed and manage their mutual trust. For example, implement the OAuth protocol in a DMZ perimeter zone but store tokens and associated state in the trusted network. API based integration between these different logical components also facilitates the integration of existing IT assets into a new OAuth enabled system.

I recognize many of these patterns in emerging standards building on top of OAuth 2.0 such as OpenID Connect and User Mediated Access (UMA). Coincidence? Obviously not. I expect these emerging standards to become one of the new focuses while building the next generation API management infrastructure.


API Management Deployment Models

April 9, 2012

The CEO of competitor API Management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure vs service based solutions when it comes to API management. Unintentionally, my original post has apparently hit a nerve.

Oren suggests that a “true” cloud solution can only be SaaS-based. While Amazon Web Services among others may take umbrage at that definition I am also a little confused by Oren’s statement since by most definitions Mashery is not a SaaS. Typically, a SaaS provides self-enrollment and self-service aspects. Mashery may let you manage your APIs in the cloud like Layer 7 or Apigee but it doesn’t do this without help from engagement consultants. In that way they are more akin to IBM than Salesforce.

In the end, our customers don’t get too caught up in cloud semantics. Some of our customers want to own a solution, others “rent”. Some want a solution in their datacenter, others on a public cloud. We understand that different deployment models are needed to accommodate different needs. If a cloud deployment is what you are after, try several vendors, verify what you get and compare each solution’s strenghts.