OAuth WRAP support in FriendFeed for feedback

As David Recordon mentioned on the Facebook Developer Blog, the Facebook Platform team is working to move Facebook Connect over to OAuth over the next year. As a part of that effort, we have been working with Google, Microsoft, Yahoo!, and a number of other engineers on the OAuth WRAP standard, which aims to be much simpler to implement than the existing OAuth standard.

As a part of this effort, I implemented OAuth WRAP support in FriendFeed so we could have a live implementation of the standard to play with. I am really interested in getting feedback about the standard from developers who are currently using OAuth or Facebook Connect or both. If you have never used WRAP before, try it out, and let me know what you think (the comments on this post are a great forum, or feel free to send feedback to the OAuth WRAP mailing list).

To get started:

• Register your application on FriendFeed to get an OAuth consumer key and consumer secret
• Read the OAuth WRAP specification and check out the Google AppEngine example application that implements WRAP
• Try implementing WRAP! The FriendFeed Authorize URL is https://friendfeed.com/account/wrap/authorize, and the
  Access Token URL is https://friendfeed.com/account/wrap/access_token

The FriendFeed WRAP implementation does not support refreshing tokens; the tokens never expire.

An overview of OAuth WRAP

The main difference between OAuth and OAuth WRAP is that WRAP does not have elaborate token exchanges or signature schemes. Instead, all server-to-server WRAP calls happen via SSL. The "access token," which grants your client the ability to make API calls on a user's behalf, is protected by SSL rather than by a shared secret and signature scheme.

The browser-based authorization experience looks exactly the same to an end user. First, you redirect the user to the Authorize URL (https://friendfeed.com/account/wrap/authorize) with your Consumer Key and callback URL. After the user authorizes, the server redirects the user back to your callback URL with a verification code. You call the Access Token URL (https://friendfeed.com/account/wrap/access_token) with that verification code to get back the Access Token.

After that, you simply need to make all your API calls via HTTPS, and you include the Access Token in the URL or in an HTTP header. There are no signatures, and no additional token exchanges necessary. Your API calls will look like https://friendfeed-api.com/v2/feed/home?wrap_access_token=....

My initial experience with WRAP

It was really easy to implement OAuth WRAP support in FriendFeed. I was able to implement WRAP on top of our existing support for OAuth, using the same tokens for both. As a consequence, our existing user interfaces for revoking applications work whether an app is using OAuth or OAuth WRAP. If we hadn't implemented OAuth support, OAuth WRAP would have been much easier to implement on its own because it is stateless; the verification code / access token exchange is so much simpler than the OAuth token exchange protocol.

On the client side, it was also much easier because of the lack of signatures (HTTPS calls are just as easy as HTTP with most HTTP client libraries). Using HTTPS for all requests seemed a bit weird at first, but in practice I realized I was simply moving signature calculation one level lower in the stack. I am curious how you all feel about it when you try the API out.