On Tue, Nov 24, 2009 at 10:57 AM, David Recordon
<davidrecordon@facebook.com> wrote:
>
> 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.

The OAuth _flow_ (in a browser) requires a couple additional requests
compared to Facebook Connect (in a browser). But Facebook Connect is
really a different beast since it relies on the Browser and Javascript
to magically set cookies cross domain and whatnot. I agree that it's
non-trivial to extend OAuth to cover this use case (we've sort of done
it at Six Apart and the flow is clunky and complicated). And even if
you figure out how to make the flow work you can't really make
requests purely on the client side without compromising your consumer
secret.

That said, as far as I can tell, using OAuth for delegated
communication via an intermediary (a web app or iPhone app, for
example) should be doable for Facebook. The only real differences I
see between OAuth and WRAP for this use case are:
  * WRAP requires SSL instead of signing URLs
  * WRAP renamed request token to refresh token and lets you use them
to exchange for temporary access tokens multiple times
  * WRAP has a defined flow for accepting username/password &
exchanging for an access token

I'm guessing that the big win you see is the third point, but the auth
flow is really a small part of OAuth. If the flow defined in OAuth 1.0
doesn't work for you why not create a new flow and keep the rest of
the spec?

> 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.

Again, the flow is really just half of OAuth. Maybe it'd make sense to
split the OAuth flow and OAuth request signing into separate specs?

> 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 seems to have a bunch of different tokens too, they just don't
call them all tokens (there's the refresh token, the client id &
secret, the access token, the verification code... everything seems to
be there).

Re: signatures, I think the SSL requirement would be a much larger
burden on developers. It's hard enough to debug OAuth problems when
you can sniff the flow using ngrep. Although I guess removing signing
would help here a bit.

> 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.

I don't think you'd be able to use GET params with WRAP since stuff
isn't signed. Other than that, I guess the terminology is simpler..?
I'm used to the OAuth terminology by now so it's hard for me to say.
The flow doesn't seem all that different to me. Maybe it's a
communication problem?

> 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.

Again, I think the only use case that would be truly difficult to
solve with OAuth is #4. I think #4 is an interesting problem though,
and I'd be happy to see OAuth support for a pure Javascript
environment.

One final note - unless I'm missing something WRAP is vulnerable to
the same session fixation attack that OAuth 1.0 had... unless it's
requiring callback registration, which is a really lame solution to
that problem.

Mike