The OAuth specification went through some significant rewrites over the past few weeks and is now, finally, ready for public review. Draft 1 has been posted today, with a planned Draft 2 next week and a final version October 1st. If you have been reading the spec over the past few months, you’ll notice that the workflow has been unified for websites, desktop applications, and mobile devices. We also simplified the signature process and added implementation details. The spec now includes a complete example from beginning to end.
From OAuth 1.0 Draft 1:
The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.
An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com.
OAuth does not require a specific user interface or interaction pattern, nor does it specify how Service Providers authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the Consumer, such as with OpenID.
OAuth aims to unify the experience and implementation of delegated web service authentication into a single, community-driven protocol. OAuth builds on existing protocols and best practices that have been independently implemented by various websites. An open standard, supported by large and small providers alike, promotes a consistent and trusted experience for both application developers and the users of those applications.
There are already a few libraries being developed for Rails, PHP, Python, C#, and others, as well as a long list of companies announcing their intention to support OAuth and add or migrate their services to OAuth. I am not expecting much to change between Draft 1 and the final specification, but we do plan to add RSA support in Draft 2.
If you are new to OAuth, start by reading my overview post and read the first few sections of the spec. If you are a technical person, the example in Appendix A is a good place to start as it shows the entire protocol step by step. OAuth is intentionally narrow and is mostly a consolidation and standardization of existing protocols. There are already plans to publish extensions that will allow automatic registration and discovery, as well as many other great ideas.