Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

Luke Shepard <lshepard@facebook.com> Sat, 03 July 2010 14:25 UTC

Return-Path: <lshepard@facebook.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC8E3A688E for <oauth@core3.amsl.com>; Sat, 3 Jul 2010 07:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZUrFft9Y4pg for <oauth@core3.amsl.com>; Sat, 3 Jul 2010 07:25:16 -0700 (PDT)
Received: from mx-out.facebook.com (outmail015.snc4.facebook.com [66.220.144.147]) by core3.amsl.com (Postfix) with ESMTP id 189F33A686E for <oauth@ietf.org>; Sat, 3 Jul 2010 07:25:15 -0700 (PDT)
Received: from [10.129.72.189] ([10.129.72.189:37500] helo=mx-out.facebook.com) by mta010.snc4.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id B9/E1-17559-3F54F2C4; Sat, 03 Jul 2010 07:15:16 -0700
Received: from [10.18.255.139] ([10.18.255.139:29097] helo=mail.thefacebook.com) by mta009.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 32/E1-27949-3F54F2C4; Sat, 03 Jul 2010 07:15:15 -0700
Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Sat, 3 Jul 2010 07:15:14 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Sat, 3 Jul 2010 07:15:14 -0700
From: Luke Shepard <lshepard@facebook.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sat, 03 Jul 2010 07:15:21 -0700
Thread-Topic: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)
Thread-Index: AcsauieXQHtIKRRIQhG2he6h4qbfsw==
Message-ID: <9FC614F1-2FEE-4A27-BA01-919A3EC5A424@facebook.com>
References: <AANLkTik55pORyRWj9rBrV1e4cbPGHM7Zbb1_ySUwB-bH@mail.gmail.com> <AANLkTinhZ8cUlNzAtfJM2MVFkGod8zGb4GXQ8cLZ7qTS@mail.gmail.com> <AANLkTikWHWYKoXS_shws1mheYVtwSSPM4b2J6mMIE_H7@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C7C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin5-GbdgXlvrws5UC60Plfh_tcpsODyHIoWw1mi@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C818@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2F0EB4.2000602@lodderstedt.net>
In-Reply-To: <4C2F0EB4.2000602@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2010 14:25:17 -0000

On Jul 3, 2010, at 3:19 AM, Torsten Lodderstedt wrote:

> Is something as the user agent flow used in the wild today? What security means are used their?

Yes. Facebook has shipped it: http://developers.facebook.com/docs/authentication/desktop

We require either pre-registration of the callback URL, or that the app uses a standard redirect URL on Facebook.com (which could only be used by a desktop app).

> I wonder why we do not drop the user agent flow from the spec because of security reasons. From my point of view, the web flow could be used to achieve a similar behavior except the JavaScript client could not directly obtain its access tokens.

Correct. The main purpose of the user-agent flow is to allow a Javascript client to obtain an access token without requiring the presence of a secret, or a server.

There are cases when you have an app without a server component, and you don't want to require a secret key (which can be revealed)