A New Venn Of Access Control For The API Economy

Cloud providers and many federated IAM practitioners are excited about OAuth, a new(ish) security technology on the scene. I’ve written about OAuth in Protecting Enterprise APIs With A Light Touch. The cheat-sheet list I keep of major OAuth product support announcements already includes items from Apigee, Covisint, Google, IBM, Layer 7, Microsoft, Ping Identity, and salesforce.com. (Did I miss yours? Let me know.)

OAuth specializes in securing API/web service access by a uniquely identified client app on behalf of a uniquely identified user. It has flows for letting the user explicitly consent to (authorize) this connection, but generally relies on authorizing the actions of the calling application itself through simple authentication. So does the auth part of the name stand for authentication, authorization, or what? Let’s go with “all of the above.”

However, OAuth is merely plumbing of a sort similar to the WS-Security standard (or, for that matter, HTTP Basic Authentication). It doesn’t solve every auth* problem known to humankind, not by a long shot. What other IAM solutions are popping up in the API-economy universe? Two standards communities are building solutions on top of OAuth to round out the picture:

• OpenID Connect for single sign-on (SSO): This protocol from the OpenID Foundation solves for SSO, session management, and identity claims retrieval. I first wrote about it here. You can think of it as a lightweight SAML that enables dynamic B2E, B2B, and B2C use cases, in a way that’s of particular interest to efforts such as the National Strategy for Trusted Identities in Cyberspace.
• User-Managed Access (UMA) for access management: This protocol from the Kantara Initiative solves for access control by third parties. (Disclosure: I founded the UMA standards effort and still serve as its group chair.) The initial use cases included an individual Web 2.0 user sharing calendars, health data, and more with friends, family, and organizations in their lives. New business-related use cases include enterprise oversight of employees’ use of cloud services. You can think of it as a lightweight XACML without the policy expression language, which enables loose coupling of authorization decisions and enforcement.

Time for a new Venn diagram, methinks…

There's no doubt about it: these OAuth-based efforts are nascent. The Implementer’s Draft specs for OpenID Connect just passed a vote of the OpenID Foundation membership on February 16 and interoperability testing among seven implementers, including Google and eBay is under way. UMA has four implementations to date, and will hold its first face-to-face interop event in April. But I’ve been discovering in a number of client conversations that IT and business organizations already have “holes” in their solution spaces that this union of Venn features helps to solve, and they welcome news of solutions that are web-friendly, lightweight, and able to be loosely coupled.

The new universe of open APIs that need serious protection – Accessibility with Security, as Google engineer Steve Yegge termed it in his famous rant – is yet more reason why I believe the “identity singularity” is on its way. We’ll be publishing some research soon on this phenomenon writ large, which we’re calling Zero Trust Identity. For now I’ll leave the obvious comparisons within the Venn as exercises for the reader, and I welcome your thoughts, questions, challenges, and use cases.