Ryan Heaton just posted to the OAuth list about OAuth for Spring Security:

I just wanted to officially announce the release of OAuth for Spring Security. I’ve had a working implementation now for quite some time, but I wanted to delay the official release until Spring Security 2.0 was released.

My hope is that this new library will make OAuth more accessible to the Java development community, a large percentage of which is already using Spring and Spring Security. I suspect that this will also make OAuth accessible to users of Grails (which is also built on Spring).

(Reposted from FactoryCity).

Eran just announced the second draft of OAuth Discovery, the first implementation of the XRDS-Simple specification that I mentioned here just over a week ago.

What’s significant about this announcement, as Eran points out, 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.

This draft is a complete rewrite of the first draft released several months ago and, in the spirit of OAuth, greatly simplifies the concepts and presentation of the protocol, and incorporates a great many of the clarifications provided by the OAuth and XRI communities.

OAuth Discovery, simply, is an extensible, machine-readable format for identifying OAuth-protected resources and service endpoints. Take a look at the provided example or Ma.gnolia’s actual discovery profile to get an idea for what these documents look like.

Over time, the goal is to automate the pairing of unacquainted web services, by being able to first identify the location of services on the web and second to discover the authentication requirements for accessing such services. Coupled with XRDS-Simple, you can further specify the types of data available from given services, and to begin to describe the methods you would use to access that data.

To provide a more complete conceptual model, imagine that you run a social network, and in this network, members have collections of bookmarks. Your service provides a way to either upload bookmarks directly or to subscribe to someone’s existing bookmarks stored at, say, services like Delicious or Ma.gnolia. Now say that you also encourage new members to sign in with an OpenID identity. From that identity, you may be able to discover an XRDS-Simple profile that points to an existing social bookmarking account, allowing you to attempt to import those bookmarks immediately. If, however, those bookmarks require authorization, and the authorization protocol happens to be OAuth, you should be able to automate the appropriate authorization requests to the user because the service supports OAuth Discovery.

In contrast, to achieve the same flow today, you must manually provide the names of accounts and services that you use individually, and then hope that the new service supports the remote protocols of your pre-existing services. With XRDS-Simple and OAuth Discovery, much of this work is automatically handled for you, letting you focus more on what you want to share, and less on where your data is stored, and increasingly allowing data to automatically flow between systems, should you decide to provide them authorization to do so on your behalf.

If you’re interest in learning more about OAuth Discovery, the best place to go is the OAuth Extensions group. Since OAuth Discovery also borrows heavily on XRDS-Simple, you might also want to check out that specification and discuss it in the related group.

December 4, 2007 – The OAuth Working Group is pleased to announce publication of the OAuth Core 1.0 Specification. OAuth (pronounced “Oh-Auth”), summarized as “your valet key for the web,” enables developers of web-enabled software to integrate with web services on behalf of a user without requiring the user to share private credentials, such as passwords, between sites. The specification can be found at http://oauth.net/core/1.0 and supporting resources can be found at http://oauth.net.

Developed through the standardization of the best practices of several well established proprietary industry protocols, OAuth is similar to Google AuthSub, FlickrAuth, AOL OpenAuth, Yahoo BBAuth, Upcoming API authentication, and Amazon Web Services API authentication.

However, OAuth is non-proprietary, and does not require a specific user interface or interaction pattern. Service Providers do not have to specify how they authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the websites, such as with OpenID. OAuth is designed to complement, rather than replace, authentication protocols such as OpenID.

Application developers can easily and safely create “mashups” across multiple web services, and web site developers can enable rich user experiences without their users sharing passwords with untrusted sites. OAuth was carefully designed for the needs of service providers ranging from the smallest PHP application to the largest industry scaled web services platforms, and for the needs of consumers such as multisite mashups, desktop tools, cellphones, set-top boxes, and internet connected appliances.

Open source code libraries are available for PHP, Ruby, Python, Java, C#, and Perl. More information and complete documentation can be found at the project homepage http://oauth.net.

Check out Leah Culver from Pownce talking about OAuth on Hacker.tv. Here’s here slides on Slideshare. Awesome introduction to OAuth!

Marc Worrell has announced the availability of a PHP-based implementation “work in progress” OAuth server and client along with the templates from their anyMeta CMS.

This comes as an alternative to Andy Smith’s code currently checked into the OAuth Code Repository, is licensed under GPLv2 and has been tested with PHP 5.2.3.

George Fletcher just checked in the port of Jon Crosby’s Objective-C OAuth Consumer Framework to Tiger into the OAuth Code Repository.

You can get the code via anonymous SVN here.

Thanks to George and Jon for their great work on this project!

And don’t forget to check out Jon’s complete guide to using the OAuthConsumer framework for Mac apps.

Nsyght, a personal search tool, has announced support for OAuth as a consumer of Ma.gnolia’s recently released OAuth Endpoint.

Geoffrey McCaleb has summarized the benefits:

What does that mean? Think of oauth as OpenID for data. Currently, if you wish to setup full bookmark syncing with your del.icio.us account, you need to provide us with your credentials. Hey, we are not going to skip town with that data or sell them to spammers, but how do YOU know that we aren’t?

In steps oauth. Our first target integration is with the excellent Ma.gnolia service. In fact, we owe a lot to our implementation to both Todd Sieling at Ma.gnolia (for getting us excited about oauth), and Andy Smith for providing a nice tidy library which was easy to extend for our use.

What does that mean for you? Well now you can sync your bookmarks with your Ma.gnolia account, and as other services around the web roll out oauth support, we will be able to hook into them rather quickly. We like easy things that bring great benefit, if only life was like that.

We’d be remiss not to make a mention of the new OpenSocial APIs that came out this week and how they do and don’t relate to OAuth.

There actually isn’t too much to report as Google is using AuthSub for the API at the moment, but, according to ReadWriteWeb, Google’s Kevin Marks said, At the moment, it is delegated to the containers. Clearly this needs to work better. We are looking at OAuth.

As Google (and others) has been involved in the development of the OAuth spec, we’d love to see Google and other service providers consider using OAuth for OpenSocial applications (and efforts are already underway to combine them); it was designed with this kind of widespread use in mind and with these kind of applications at their center. After all the work that’s gone into OAuth so far, from various industry leaders and grassroots developers, it’s the perfect timing, with Final Draft 5 out, to put OAuth into production.

This is great advice from Gabe Wachob — in fact, good enough to reproduce in its entirety:

Memo to OAuth Service Providers: think of your consumers as your partners, and not just "users".

• Understand that many of the consumer applications of your service are driving users to your site,
  and in the world of composable services, your consumer application developers
  will often have choice. Choice means power. Recognize.
• Keep the channels of communication open with developers of consumers of your service. Use blogs, email lists, IRC channels, and show up at community events that are relevant to your service (barcamps, superhappydevhouse, etc).
• Be transparent about API changes - try to schedule changes ahead of time, try to keep changes limited to a regular scheduled time, be prepared to rollback changes, and be especially available immediately after API changes.
• Think like a service provider and be concerned about security, availability and uptime, even if nobody is directly complaining - remember, your service availability may impact the perceived quality of the services offered by consumer applications.
• Be transparent about outages - you will have more credibility with your consumers (see above about choice).
• Be proactive about supporting consumer applications - know which consumer applications are accessing your service - you never know who your friends might be. I suspect OAuth will be a great channel for business development!

Service providers who do this well: Linden Labs (Second Life), Pair Networks.

If you’re interested in this topic, I’ll be at SuperHappyDevHouse 20 this weekend, and at a OAuth implementers meetup at SHDH20.

October 4, 2007 – The OAuth Working Group is pleased to announce publication of the Final Draft of the OAuth Core 1.0 Specification. OAuth (pronounced “Oh-Auth”), summarized as “your valet key for the web,” enables developers of web-enabled software to integrate with web services on behalf of a user without requiring the user to share private credentials, such as passwords, between sites. The specification and supporting resources can be found at http://oauth.net.

Developed through the standardization of the best practices of several well established proprietary industry protocols, OAuth is similar to Google AuthSub, FlickrAuth, AOL OpenAuth, Yahoo BBAuth, Upcoming API authentication, and Amazon Web Services API authentication.

However, OAuth is non-proprietary, and does not require a specific user interface or interaction pattern. Service Providers do not have to specify how they authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the websites, such as with OpenID. OAuth is designed to complement , rather than replace, authentication protocols such as OpenID.

Application developers can easily and safely create “mashups” across multiple web services, and web site developers can enable rich user experiences without their users sharing passwords with untrusted sites. OAuth was carefully designed for the needs of Service Providers ranging from the smallest PHP application to the largest industry scaled web services platforms, and for the needs of consumers such as multisite mashups, desktop tools, cellphones, set-top boxes, and internet connected appliances.

Open source code libraries are currently being developed for PHP, Rails, Python, .NET, C, and Perl. More information and complete documentation can be found at the project homepage http://oauth.net.