Re: [OAUTH-WG] Draft -07 (major rewrite)

Marius Scurtescu <mscurtescu@google.com> Wed, 16 June 2010 01:04 UTC

Return-Path: <mscurtescu@google.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 1EA5D3A68CD for <oauth@core3.amsl.com>; Tue, 15 Jun 2010 18:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.285
X-Spam-Level:
X-Spam-Status: No, score=-105.285 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 eS52UPdGBLoJ for <oauth@core3.amsl.com>; Tue, 15 Jun 2010 18:04:52 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E4C4E3A6A8A for <oauth@ietf.org>; Tue, 15 Jun 2010 18:04:51 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5G14sCj014273 for <oauth@ietf.org>; Tue, 15 Jun 2010 18:04:55 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276650295; bh=A1M9pMFT7onflCY9My9X0bn59SQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZDKNut5yScy8Yjb4+AF3GaoFdrD/Xoh/ef8QNydDEWTdTksqCo+1QxccbqTv7Ek0T DHnlFDiX33+aTrb5lw1bw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=VUQXXSxu/pFKR67xBUb6dIH1r/r4RS1rxGRJSMBMCC7UpG52AioVTzyzRar0EjQVG dP03t0oAciUCtEC64ikpw==
Received: from ywh37 (ywh37.prod.google.com [10.192.8.37]) by hpaq2.eem.corp.google.com with ESMTP id o5G14qYe010790 for <oauth@ietf.org>; Tue, 15 Jun 2010 18:04:53 -0700
Received: by ywh37 with SMTP id 37so4091279ywh.2 for <oauth@ietf.org>; Tue, 15 Jun 2010 18:04:52 -0700 (PDT)
Received: by 10.101.200.6 with SMTP id c6mr6933896anq.234.1276650292220; Tue, 15 Jun 2010 18:04:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.189.37 with HTTP; Tue, 15 Jun 2010 18:04:32 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin_3ZUINYkl8YJCTbqAQgPM47AqTvjLN81tMtFS@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimr934H8K-4n7Xu6GG7M78TsHAtP6q9MSk7JZjl@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik8OjFz_RvmC4SKLTV4PTERPsrwSL9FsPSRN7db@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 15 Jun 2010 18:04:32 -0700
Message-ID: <AANLkTikfiFOwPm4Y74OytadzPrrA3pEyWMfX80LCKQxU@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
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: Wed, 16 Jun 2010 01:04:53 -0000

On Tue, Jun 15, 2010 at 5:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Because that defeats the point of having two different access tokens, one issued with a client secret and the other without.

If the authorization code is passed by the JavaScript client to the
client server, then the client server can use its secret if it has
one. Access token with client secret can be issued.

If the authorization code is swapped directly by the JavaScript client
then it is clear that there is no secret (based on both client id and
the fact that no secret is sent), access token with no client secret
is issued.

Where does Web Server vs User-Agent make a difference?


> It also requires the JS client to interact a lot more with the server part and wait for responses (no needed when it just sends over the authorization code).

Maybe, but it would be good to see in detail such a case. When does
the JavaScript interact a lot more and why?


Marius

>
> EHL
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Tuesday, June 15, 2010 5:24 PM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> It gives you a hybrid solution. The user-agent client doesn't not need to keep the client secret, but can still move the authorization code to its server component to obtain a longer lasting refresh token. It also allows the server to manage the two tokens using different policies (the one obtained using the user-agent flow directly and the one obtained using an authenticated client call on the server).
>
> OK, but why cannot this be done with the Web Server profile? The JavaScript client can start the Web Server profile and at the end it gets an authorization code (as a query parameter as opposed to
> fragment) which it can pass to the its server...
>
>
> Marius
>
>>
>> EHL
>>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> Sent: Tuesday, June 15, 2010 4:19 PM
>> To: Eran Hammer-Lahav
>> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>>
>> On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>>> Adding a verification code to the user-agent flow was suggested on
>>> this list and received nothing but support. It was suggested as a
>>> solution to a Twitter use case.
>>
>> I think it would be good to see a detailed use case where this is really needed and the previous Web Server and/or User-Agent flows could not do.
>>
>> A Java-Script client can use the Web Server flow to grab a verification code and then either swap it or pass it down to the client server.
>>
>> Marius
>>
>