It’s About (OAuth) Discovery

I’m happy to announce the publication of the OAuth Discovery 1.0 specification first draft. OAuth Discovery enables partial and full automation of the OAuth protocol by using a machine-readable OAuth configuration documents. What is even more exciting is that we already have two Service Provider implementations available for Nouncer and Ma.gnolia, upcoming support from Twitter, and are expecting a Consumer library and test server soon. As with any first draft, the specification is expected to change and feedback is highly appreciated.

During the OAuth Core development process, many people brought up the idea of using OAuth in a fully automated mode. Usually it came up after they have tried to incorporate OAuth into an existing tool, such as CURL, only to realize there are just too many OAuth parameters provided in manual documentation for a simple and usable interface. This is particularly true when considering the fact that in many cases, OAuth is replacing HTTP Basic Authentication which is a fully automated process (except for asking the users for their credentials).

Two weeks ago I implemented an initial concept for OAuth Discovery using existing discovery concepts from the OpenID and XRI worlds. I’ve presented it at IIW at the OAuth Extensions session and got some very positive feedback. The challenge of turning that initial implementation into a specification was that unlike OAuth Core, a discovery workflow is all about interoperability and must be accurate so that different implementations can work together flawlessly. OAuth Core leaves much out of scope, and it is both good and unavoidable.

The OAuth community motto has been from early on: “Don’t invent – reuse”. When applied to developing Core, we rejected proposals from both authors and contributors for features that were not well established in the wild. One such example is a proposal for a preferred language extension which allows a Consumer to indicate to the Service Provider the User’s preferred language during the authorization step. The language preference extension draft has been published this week by George Fletcher (AOL) and John Kemp (Nokia).

When the motto is applied to discovery, it means building a framework that can accommodate future extensions without trying to predict or define them. OAuth Discovery uses the XRDS format together with Yadis to deliver the OAuth configuration in a machine-readable format. It uses URIs to label features and services, and can be implemented for simple and complex scenarios.

To learn more about the proposal and to participate in the discussion, visit the OAuth Extension group.

Comments

[Chris Messina]

Bravo! More great work Eran -- you're on a roll! ;)

[Scott Kveton]

Eran: this is great news and its fantastic that you're using existing technologies. I'm still trying to wrap my head around interoperability here ... do you envision a way for OpenID providers to act as OAuth end-points for both service discovery and authentication? I'm just thinking that with most (all?) OpenID providers supporting Yadis and the XRDS format, it would be great to be able to add OAuth as one-more-thing-your-provider-can-do. I just can't figure out how the actual flow would/could (should?) work.

Either way, great work ... keep it up! :-)

[Eran Hammer-Lahav]

Thanks! There are a lot of possible use cases for this and using XRDS allows the smooth integration with OpenID providers. At this point the focus is on two main cases:

1. The Service Provider doesn't care much who is the Consumer, as long as the User agrees to it. This is exactly what HTTP Basic Auth does, if you think about the browser as the Consumer.
2. Most services require some hard-coding of their API, so while it could be cool to just copy/paste a Flickr URL for a private photo and get prompt for OAuth login, the real benefit is using a single XRDS URL to configure OAuth. Instead of manually hardcoding the endpoints, signature methods, etc. developers will just provide the Service Provider's discovery realm which will include all they need. It will also allow the SP to make changes without breaking the Consumers.

There are many more possible use cases, but these two are the initial trigger.

[Paul Prescod]

"unlike OAuth Core, a discovery workflow is all about interoperability and must be accurate so that different implementations can work together flawlessly."

What does this mean? How is interoperability and accuracy less important for OAuth Core?

[Eran Hammer-Lahav]

Core defines a protocol between a specific Service Provider and its Consumers. The manual OOB requirements make it more of a framework than an interop protocol. Just because I say I am using OAuth Core to provide access via my API, doesn't mean anyone who can talk OAuth case use this service. They still have to figure out what the actual service is.

When we talk about automated discovery, the goal is to remove the developer from the flow, and allow one service to "magically" talk with another, assuming they both understand the way resources work.

[Paul Prescod]

"Most services require some hard-coding of their API, so while it could be cool to just copy/paste a Flickr URL for a private photo and get prompt for OAuth login, the real benefit is using a single XRDS URL to configure OAuth."

I think that there is quite a bit of chicken and egg going on: if the authentication is going to be proprietary then the whole API might as well be and vice versa.

I hope that you do address the use case of using a REST-y, URL-centric approach to resources. Is there any reason that it should be more complicated in the simple case than HTTP auth?

I don't claim to have thought through these issues and I'll have to put aside some time to do that soon....but this discovery thing has a bit of a WSDL-smell that makes me nervous. It is better to standardize behaviours than to standardize the description of behaviours. If you standardize the description, you still have to actually implement the behaviours.

[Eran Hammer-Lahav]

I think the spec is going to get simpler as we progress. Except for some small changes, I don't think we need any *more* features.

I agree about the chicken and egg game, and I think auto-configuration of OAuth endpoints is going to be the way most services will start using OAuth Discovery for. Once we have enough of those, people will start figuring out more shortcuts.

At the end this is a balance between simple and flexible, and given that we don't have much to learn from, we have to invent a little bit. If you look at the Ma.gnolia XRDS file, it is pretty simple. Nouncer is more complex, but also easy to understand even if you never read the discovery spec.

What I think is key is to make sure we have working examples before releasing the discovery work. If developers refuse to use it, we know it is not the right solution. We already have people building Consumer code and as with any early drafts, changes are expected.

[Anton Bar]

Is it just me or the spec URL is broken? Now it returns an empty page... :-(