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.