Re: [OAUTH-WG] Issue: state in web server flow

Marius Scurtescu <mscurtescu@google.com> Mon, 19 April 2010 23:41 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 B91823A67A3 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 16:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.888
X-Spam-Level:
X-Spam-Status: No, score=-105.888 tagged_above=-999 required=5 tests=[AWL=0.089, 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 B9+PkSjQFuiE for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 16:41:22 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6A86B3A689C for <oauth@ietf.org>; Mon, 19 Apr 2010 16:41:21 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o3JNfBZ5032430 for <oauth@ietf.org>; Mon, 19 Apr 2010 16:41:12 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271720472; bh=VckmHSrCAN+GRGi8eey9d7oSLhI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iUdg1VhhjDfNdDUR0SQorxICm/QUhd3HyOLwpj87nstA4PrppKV3IG49ivmAnBdCu 5RDJ00KJwfuXibC7NJUXw==
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:x-system-of-record; b=uL4eHPY7gJ3IO0LCm2/sH/g+Vt46vWF61e32wnOCXCwDI0+Tcra0AuH7qejEnlFZB wWfnBZdAlAyYl4CSsmwzA==
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by wpaz17.hot.corp.google.com with ESMTP id o3JNaBci015051 for <oauth@ietf.org>; Mon, 19 Apr 2010 16:36:11 -0700
Received: by pzk10 with SMTP id 10so240868pzk.20 for <oauth@ietf.org>; Mon, 19 Apr 2010 16:36:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.107.2 with HTTP; Mon, 19 Apr 2010 16:30:08 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F2C8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <1E39CE38-763E-4E3D-96D4-DC757BD53B9D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4776FFF7-45E6-4945-9548-382A9DB84A95@gmail.com> <r2v74caaad21004191017id7c48d54lc5ced6e9e164591e@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F1BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <t2s74caaad21004191358h3527f320u61c6a958cda1d652@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F2C8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 19 Apr 2010 16:30:08 -0700
Received: by 10.140.58.5 with SMTP id g5mr709503rva.157.1271719828214; Mon, 19 Apr 2010 16:30:28 -0700 (PDT)
Message-ID: <k2h74caaad21004191630k4f6cf28ar5f5949955c26ff04@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: state in web server flow
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: Mon, 19 Apr 2010 23:41:22 -0000

On Mon, Apr 19, 2010 at 2:24 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> Sent: Monday, April 19, 2010 1:58 PM
>> To: Eran Hammer-Lahav
>> Cc: Dick Hardt; OAuth WG
>> Subject: Re: [OAUTH-WG] Issue: state in web server flow
>>
>> On Mon, Apr 19, 2010 at 11:53 AM, Eran Hammer-Lahav
>> <eran@hueniverse.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> >> Sent: Monday, April 19, 2010 10:18 AM
>> >
>> >> I don't think it is possible to enforce callbacks without any query
>> parameters.
>> >> See the Drupal example.
>> >
>> > In the Drupal example the client server adds its silly parameters internally.
>> They are not included in what the client provides as its callback URI.
>>
>> Silly?
>
> Yes.
>
>> The query parameter may or may not be visible in the registered callback.
>>
>>
>> > Can you give an actual callback URI example?
>>
>> http://example.com/oauth2/callback
>> equivalent with:
>> http://example.com/index.php?q=oauth2/callback
>
> Why can't the client always use the first?

For the PHP code receiving the callback makes absolutely no
difference, in both cases it sees the second.

The first URL is achieved with Apache doing a rewrite, it acts as a
reverse proxy. The backend code is always called with the query
parameters.


>> > Also, if the client requires query parameters in its callback, it just means it
>> cannot use the client state OAuth parameter.
>>
>> Sure it can, perfectly valid to redirect to:
>> http://example.com/oauth2/callback?code=123&state=qwerty
>> which is the same as:
>> http://example.com/index.php?q=oauth2/callback&code=123&state=qwert
>> y
>
> No, I meant according to the last proposal, the state parameter will be limited to cases where there is no query in the callback URI. This makes it easy for servers to validate the pre-registered URI.

Servers can validate pre-registered URIs even of the callback has
query parameters, including strict matching.


Marius