IETF Logo Mail Archive

Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 19 July 2011 06:32 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B921F85AC for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2011 23:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+qqTbnh2Qq1 for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2011 23:32:44 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E373521F8577 for <oauth@ietf.org>; Mon, 18 Jul 2011 23:32:43 -0700 (PDT)
Received: (qmail 10029 invoked from network); 19 Jul 2011 06:32:43 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 06:32:43 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Jul 2011 23:32:43 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Eliot Lear <lear@cisco.com>, Bob Van Zant <bob@veznat.com>
Date: Mon, 18 Jul 2011 23:32:20 -0700
Thread-Topic: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
Thread-Index: AcxEZuTF9ic1HEHFTOKq4n5iFn1w9gBdhXKA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0656@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CADrOfLJSd8Z=QfCcGUdFBU314rmjv9-u25Vta+ObXfNAwoA06w@mail.gmail.com> <4E22B021.7080009@cisco.com>
In-Reply-To: <4E22B021.7080009@cisco.com>
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>
Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 19 Jul 2011 06:32:44 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eliot Lear
> Sent: Sunday, July 17, 2011 2:49 AM

> One other point: if the redirection_uri can have fragments and can be
> provided, why is state necessary?

First, I assume you mean query instead of fragment.

This was discussed on the list about a year ago. There isn't a requirement to support both dynamic redirection URIs as well as a special state parameter. However, the state parameter provides a better way to allow customization of the redirection request alongside full registration of the redirection URI. Section 3.1.2 recommends using the state parameter over changing the redirection URI itself.

Using state is much simpler because the authorization server does not have to implement potentially insecure URI comparison algorithms for dynamic redirection URIs.

EHL

v2.29.0 | Report a Bug | By Email | System Status