Glue Conference, aka Gluecon, is such a refreshing event – filled with API and application developers, not a single suit in sight, demo pods, hackathons, spheros etc.

APIs are popping up everywhere and creating amazing integration possibilities. One of the coolest demos I saw at Gluecon was Ducksboard’s dashboard service, which lets you create your own monitoring dashboard using a library of widgets for existing social and Cloud providers. You can even create your own widget and have your own data pushed to it via an API endpoint created just for you, on the fly – so sexy!

Thanks to everybody who came to my presentation Making Sense of API Access Control. I hope this shed some light on how to leverage OAuth for controlling access to REST-based APIs. A lot of the new APIs I discovered this week could certainly use some help in that regard. API key authentication in HTTP basic without password has its limitations. The slides from Making Sense of API Access Control are embedded below.

When talking about API management, the first thing that comes to mind is a public API, one that is open for anybody to consume, provided a certain level of registration. Obviously, the most famous APIs are the public ones, potentially known to anybody. However, such APIs only represent a small subset of all APIs that need to be managed. Many APIs that we encounter in the field are set up in such a way that their consumption is restricted to a specific group of developers. This happens for various reasons. Some talk of public and private APIs, others use the terms open and closed to represent the same distinction.

Most of the time, even public APIs start off as private APIs – as part of their development lifecycle. Until an API has been fully tested and is ready to be launched, it remains private and only accessible to its internal developer base. The ability to “flick the switch” on an API, to make it jump from a staging mode to a live mode, is an essential feature of an API management infrastructure.

Then there are APIs that are never meant to be public in the first place. Most APIs actually fall under this category. Many enterprises that are moving forward with API management are exposing APIs privately – for example, to facilitate the creation of custom mobile apps for their employees, in order to tap into the BYOD trend. Those APIs are intended to be consumed by their own developers, contractors and sometimes partners.

The Layer 7 API Portal is geared towards managing APIs that are either public or private and lets API managers control which developers are made aware of which APIs. This lets you have a single point of management for all APIs, regardless of their target audience. By default, only public APIs are visible on the API Portal.

A series of tutorial videos for the API Portal product has recently been posted on our YouTube channel. As it happens, one of videos is called Publish a Private API and it’s embedded below.

OAuth 2.0 seems to be on everybody’s minds 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 of 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 SecureSpan Gateway platform – a testament to the flexibility of that platform. Then, leveraging precious feedback from numerous architects applying OAuth with our Gateway, the OAuth Toolkit matured; became a product of its own. Today, we’re witnessing the third evolution phase: OAuth is making its way to the very core of the SecureSpan 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 be among the new focuses while building the next generation API management infrastructure.

The CEO of competitor API management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure-based versus 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 a data-center, others in 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 strengths.

OAuth handshake patterns and OAuth token management are currently two of the hottest topics related to enterprise APIs. Although OAuth originated as a third-party authorization mechanism, it now addresses a multitude of patterns related to controlling access for RESTful APIs. With version 2.0 of the standard defining numerous grant types that accommodate both two and three-legged cases, OAuth is becoming the de-facto standard for any API access control.

Regardless of the specific access control scenario, any enterprise-scale OAuth implementation must leverage existing infrastructure and processes for managing and controlling identities. For example, OAuth should be implemented in a way that maintains any existing Single Sign-On user experience or it should simply reuse existing identities and their attributes as part of the authorization checks.

Next Wednesday, I’ll be joined by Steve Coplan of 451 Research for a webinar called Simplifying API Access Control with OAuth. We’ll be taking an in-depth look at just how OAuth can be integrated with existing systems for effective API access control. We’ve already had a lot of interest in the event but there are still a few free spots, so don’t hesitate to sign up for the webinar today.