[OAUTH-WG] Facebook, OAuth, and WRAP

[David Recordon <[e-mail]>]

Hey all,
This was originally a comment on Eran's post about WRAP (http://hueniverse.com/2009/11/wrap-and-the-demise-of-the-oauth-community/).  Beyond Luke and I talking at the Internet Identity Workshop a few weeks ago, I don't think we've actually articulated where Facebook is thinking in regards to OAuth.  In order to help get OAuth 2.0 done, I wanted to make sure we've shared where we see OAuth 1.0 falling short, why we're interested in WRAP, and the four main use cases our current proprietary authentication mechanism solves.  We've also signed Open Web Foundation agreements for OAuth Core 1.0a and the WRAP specs (http://developers.facebook.com/news.php?blog=1&story=335).

The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new RFC is awesome) is the increase in the number of HTTP requests that developers will need to make in comparison to our current authentication mechanism.  We want to move to using OAuth, but for this reason and hearing strongly from other major implementors that OAuth has not been widely adopted by their developer communities because it is too difficult to correctly implement has us concerned.

The most interesting part of WRAP are the various profiles.  They currently map well to our existing authentication mechanisms and the username/password profile is an API we offer to whitelisted partners such as the XBox and Playstation 3.  It would be great if OAuth 2.0 had a similar profile mechanism where each profile is optimized in terms of the number of steps (HTTP requests) required versus being combined together like OAuth 1.0.

I'm not convinced that signatures are "too hard" for developers especially when libraries hide them away.  That said, OAuth 1.0 implementations still requires that developers understand the different types of tokens in addition to when and how they're generated.

WRAP is intriguing in terms of really simplifying what developers need to understand.  The first step being trading some set of credentials or asking the user to go somewhere results in an access token.  The second step then being including that access token via HTTP headers, a GET arg, or a POST arg over SSL without needing to calculate any sort of signatures.  The downside is that now all APIs need to be served over SSL, but that seems doable.

These are the four main use cases which were focused on.  While there is quite a bit of overlap between them, we think that it is important to have specifically optimized flows for each so that individually they are as simple as possible to implement.

1) "OAuth" web flow of redirecting a user to Facebook, them authorizing pre-registered application, and then being redirected back to the web app within their browser.
2) A mobile/desktop flow where the user is redirected back to Facebook, authorizes the app, and then is sent back to the application.  We both have a version of this use case where the application separately opens a browser and one where the application is able to embed a browser directly.
3) A mobile/desktop/device flow where the user enters their Facebook username/password which the application then trades for a token.  This is for whitelisted partners.
4) A fully JavaScript environment where the JavaScript sets a cookie containing the credentials needed for the web application to get API access while the user has an active session.

We think that WRAP currently solves #3, probably solves #2, and mostly solves #1.  #4 hasn't been tackled within WRAP yet, but we hope to develop a profile for it as well.

I'm happy to participate in the IETF to help develop OAuth 2.0 and to encourage others from Facebook to do the same, but also want to be really pragmatic around having something we can ship (either WRAP or 2.0) sooner rather than later.

Cheers,
--David