Re: [OAUTH-WG] Facebook, OAuth, and WRAP

Brent Goldman <> Wed, 25 November 2009 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA98E3A69C3 for <>; Wed, 25 Nov 2009 06:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.964
X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Qwq7B-+9eyA for <>; Wed, 25 Nov 2009 06:03:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C15333A6AC0 for <>; Wed, 25 Nov 2009 06:03:33 -0800 (PST)
Received: from ( [] (may be forged)) by (8.14.1/8.14.1) with ESMTP id nAPE3HHI028683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 06:03:17 -0800
Received: from ([]) by ([]) with mapi; Wed, 25 Nov 2009 06:03:26 -0800
From: Brent Goldman <>
To: Mike Malone <>
Date: Wed, 25 Nov 2009 06:03:23 -0800
Thread-Topic: [OAUTH-WG] Facebook, OAuth, and WRAP
Thread-Index: Acpt2A6RpCBQZoxRTBq7PY9v2AIxPA==
Message-ID: <>
References: <AcptN/sGLUJPJF8VTBWs8YsEibJh6w==> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C6B20C22ED3A4714943FFEA0A2347045facebookcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-25_10:2009-11-16, 2009-11-25, 2009-11-25 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911250105
X-Mailman-Approved-At: Wed, 25 Nov 2009 07:43:43 -0800
Cc: Naitik Shah <>, Luke Shepard <>, "" <>
Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2009 14:05:06 -0000

On Nov 24, 2009, at 4:35 PM, Mike Malone wrote:

On Tue, Nov 24, 2009 at 10:57 AM, David Recordon
<<>> 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

Facebook Connect can work without cookies (e.g., in a Safari iframe, or if the developer manually turns this off via a configuration option) -- the cookies are just used as a simple cache, and are not magic or a defining feature of Connect. Additionally, by default, Connect does not work across domains unless the developer configures a base domain with us. To top it all off, Connect also works in a non-JS environment, or in an environment where the developers don't want to use the Facebook JS.

Therefore, I think we can fairly compare OAuth and Facebook Connect apples to apples, and we should just consider cookies, multiple domains, and JS snazziness as extra features that would be nice to add to OAuth via extensions. As David stated, the largest issue with Facebook moving to OAuth truly is the number of requests.

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 third point is pretty cool, but Facebook actually discourages exchanging usernames/passwords for access tokens. Only a handful of whitelisted partners have access to this.  In the vast majority of cases, usernames and passwords are given directly to<> instead of to the app.

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?

This is a really interesting idea that I think makes a lot of sense. I don't see why the various WRAP profiles couldn't work almost identically in OAuth 2.0, with the main differences being that OAuth 2.0 would have an extra step to exchange a secret (or perhaps even reuse a step if it makes sense, and then API calls would have a signature instead of being called over SSL.

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.

Good point about the tokens. One of us should make a list of all the terms in each spec, and then set up a mapping between the sets, to see if the number of concepts is really all that different.

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?

Why does the lack of signatures mean we can't use GET params? We can still trust everything because it's happening over SSL.

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

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.