It’s always gratifying to announce new specifications or new drafts of existing efforts. OAuth Discovery has been in development for over five months and has matured a great deal since its initial introduction at the Internet Identity Workshop. I am happy to announce the availability of the OAuth Discovery 1.0 Draft 2 specification which is also the first implementation of the recently announced XRDS-Simple format.
What makes this announcement significant is that the new draft is already implemented and deployed by FireEagle (a Yahoo! Brickhouse service), Ma.gnolia, and Get Satisfaction – three leaders in the OAuth community. On the development tools front, Mediamatic will release initial support for discovery early next week with full support due early May in their OAuth PHP library.
The first draft of OAuth Discovery published four months ago started a dialog and was the main driver behind the development of XRDS-Simple. The second draft incorporates most of the feedback received from the OAuth community, primarily the adoption of XRDS without properly explaining it, and the introduction of an entirely new vocabulary that was unfamiliar. The new draft has been completely rewritten, offering an extremely simple solution in the spirit of the OAuth Core specification.
XRDS-Simple defines a workflow for finding information about resources using their URIs. This fits well with the idea of OAuth Discovery where a resource protected by OAuth points to a machine readable document containing the configuration needed to access the resource. With that idea in mind, OAuth Discovery has been revised to fit into the general resource discovery flow, where the OAuth configuration is but one of potentially many other attributes associated with the resource. By using the entire XRDS-Simple workflow, OAuth Discovery adds little new, focusing on the narrow scope of providing OAuth configuration in a machine readable format.
When OAuth Discovery was first introduced, many people expressed skepticism regarding its usefulness. In private conversation with some leading service developers, many expressed a similar view that there is little value in automated discovery with proprietary APIs. That is, if the developer has to manually write code to handle a site-specific API, discovery doesn’t save much (if any) work. While this is generally true, it misses one important use case of OAuth Discovery – library interface and automatic configuration.
OAuth enjoys a wide range of open source libraries. However, they all require some form of hard coding the OAuth endpoints and the signature methods supported by the service providers. If in the future, the service providers add support for new extensions or change their OAuth configuration, the developer will have to manually apply these changes. This is especially true to features that enhance the security and reliability of the protocol.
OAuth provides a flexible framework for access delegation which is compatible with any authentication protocol including OpenID. With discovery information in place, we can move closer to the day when OAuth drives access to most of the protected resources on the web. As soon as we have a wide range of discoverable resources, we can make the case for built-in browser support for OAuth and discovery, enabling developers to implement a single protocol for all their access control needs, regardless if it is being used by an API developer or an end user visiting a site with a browser.
To learn more about OAuth Discovery please read the specification (you might want to take a look at the XRDS-Simple draft as well), check out the discovery documents provided by FireEagle, Ma.gnolia, and Get Satisfaction, and join the conversation at the OAuth Extensions Google Group.