Piling On OAuth
For those who’ve read my previous OAuth posts, the title for this article is a double entendre. I mean to convey both the idea that I’m piling on OAuth assurance AND that the entire industry seems to be piling on new standards, profiles and implementations onto OAuth 2.0 standards “infrastructure.”
First of all, OAuth has a long list of service providers supporting either the original specification or the new OAuth 2.0 RFC. You can find this list midway down the Wikipedia page. A list of this size and a burgeoning market for apps requiring identity information represents a plethora of activity. And because it is relatively under-specified – leaving important questions such as how authentication should be accomplished and how to represent authorization scope – to the developer’s imagination, implementations tend to go in many different directions.
Third, multiple standards are being built not to assist OAuth, but to add functionality on top of it. These include:
- OpenID Connect, which I wrote about in my OAuth profiling post. OpenID Connect specifies how authentication should work on top of OAuth, and leverages it to share user identity information as a resource across sites.
- User Managed Access (UMA) provides a set of specifications that let an individual control the authorization of data sharing and service access across online services on his or her behalf. UMA defines additional authorization tokens and information flows on top of the OAuth Access Token and other concepts. As such it extends OAuth to allow multiple-person data sharing and granular authorization of resources.
- Blue Button Plus is a standards framework mandated under the U.S. Health and Human Services (HHS) Department. The Blue Button+ pull specifications will leverage OATH 2.0 to enable patients to retrieve data from health service providers as mandated for Meaningful Use. This profile of OAuth is also an early adopter of dynamic client registration to deal with a potential audience of hundreds of thousands of health care providers. But it will struggle with assurance issues. The profile is also taking on use cases of caregivers with patients or parents with children accessing their dependents’ records using a “structured scope” hack on top of OAuth, which wasn’t designed for multiple-person authorization.
Finally, to wrap all this up, those who espouse “agile development” – such as Facebook’s CEO Mark Zuckerburg’s who once touted the company’s “hacker’s way” – may shrug their shoulders at assurance issues and a proliferation of standards. Where others see chaos, they’ll see a fertile field where productivity can flourish. And it will, in some cases. The good news is that some of these problems will sort themselves out in the long term. As an industry, we should continue promoting OpenID Connect and JOSE as the ways to perform authentication and cryptography with OAuth in a more predictable and consistent manner. Similarly with UMA and advanced authorization use cases.
However, implementations will still need testing; OAuth testing is already challenging and will get more so as the suite of standards based on OAuth continue to expand and ferment. The industry will need to develop certification programs and testing tools to accommodate a wide variety of scenarios even in the best case.
Other posts in this thread: