Re: [OAUTH-WG] OAuth 2.0: client_secret, state

Marius Scurtescu <mscurtescu@google.com> Thu, 25 March 2010 22:23 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 00FAD3A6C94 for <oauth@core3.amsl.com>; Thu, 25 Mar 2010 15:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Level:
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 1LoPfNlDI-Jf for <oauth@core3.amsl.com>; Thu, 25 Mar 2010 15:23:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 745563A6BAF for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:35 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [10.3.21.2]) by smtp-out.google.com with ESMTP id o2PMNrTf028111 for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:53 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269555834; bh=tuusc2Tjo2yGjP+x1PDk+xnFcu8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=lQ738IM2R7wJ8TFiqLvilxjlF+QlIZ4jjiY4Gva0Xf7Xu8l4rR3ts7Wmv79Zj3mko ZUFPJqWN49H6XbOqIp5Aw==
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=gu6f8aFGkLSOsm+gd65uKFqcETy85D2zZWea7n51ew7dcjHsDeBuTRnF/9NEx6OnT 47dK3CG+kM9Wq64H8/9+w==
Received: from fg-out-1718.google.com (fgad23.prod.google.com [10.86.55.23]) by hpaq2.eem.corp.google.com with ESMTP id o2PMNow5029859 for <oauth@ietf.org>; Thu, 25 Mar 2010 23:23:52 +0100
Received: by fg-out-1718.google.com with SMTP id d23so2298947fga.7 for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.125.13 with SMTP id c13mr995630mun.81.1269555829682; Thu, 25 Mar 2010 15:23:49 -0700 (PDT)
In-Reply-To: <fd6741651003221052x357eb64fj2ffc1544650b9599@mail.gmail.com>
References: <526C3C44-18CF-4A94-A4C6-72702F73AC83@facebook.com> <255B9BB34FB7D647A506DC292726F6E112531C851D@WSMSG3153V.srv.dir.telstra.com> <fd6741651003221052x357eb64fj2ffc1544650b9599@mail.gmail.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 25 Mar 2010 18:23:29 -0400
Message-ID: <74caaad21003251523p4dac2a5en6c4e3ae3f14e4ea@mail.gmail.com>
To: David Recordon <recordond@gmail.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>
Subject: Re: [OAUTH-WG] OAuth 2.0: client_secret, state
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: Thu, 25 Mar 2010 22:23:49 -0000

On Mon, Mar 22, 2010 at 1:52 PM, David Recordon <recordond@gmail.com> wrote:
> On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H
> <James.H.Manger@team.telstra.com> wrote:
>> 2. STATE
>> OAuth has various parameter that are used to carry state for another party in a message, which is helpful for building scalable systems. OAuth should avoid duplicating these fields or defining their semantics when they are opaque to the party carrying them. This will keep the protocol simpler, without losing any functionality.
>>
>> oauth_client_state is unnecessary as it is always accompanied by oauth_callback_url that can encode the state directly. The examples could include, say, ...callback_url=http://client.example.com/cb%3Fstate=FSR63fs&oauth_mode=... to reflect likely cases. It is still simple to compare the callback to a pre-register value if required (eg compare suffix, or compare ignoring additional query params).
>
> Has there been any discussion of the oauth_client_state parameter on
> the list?  I don't really remember it.

Not sure if this was discussed or not, but I think client state can be
really useful. Yes, client state can be added to the callback URL, but
this makes validating this URL against a registered callback URL more
difficult. This ties in with the fact that the validation of these
URLs is not specified.

It is easy to imagine an Authorization Server that does strict
validation of callback URLs, in which case the only way to pass client
state through is with this extra parameter.

Marius