Enterprise Integration Zone is brought to you in partnership with:

As the Technical Director, Europe for Layer 7 Technologies, Francois Lascelles advises global corporations and governments in designing and implementing secure SOA and cloud based solutions. Francois joined Layer 7 in its first days back in 2002 and has been contributing ever since to the evolution of the SecureSpan SOA infrastructure product line. Francois is co-author of Prentice Hall’s upcoming SOA Security book. Layer 7 Technologies is an Enterprise SOA and Cloud infrastructure provider. Follow me on twitter http://twitter.com/flascelles Francois is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Beyond OAuth – Emerging Standards for API Access Control

05.24.2012
| 6813 views |
  • submit to reddit

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.

Published at DZone with permission of Francois Lascelles, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Herry Johnson replied on Tue, 2012/06/12 - 12:58pm

Thank you. I have looked at it only briefly, but it looks like the Preferences API is suitable for storing each user's preferences (eg the last open directory, etc.). Is it really suitable for application settings, which does not change and should be the same for all users respectively for all instances of the application?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.