[OAUTH-WG] Why give the redirect URI when trading an access code for an access token?

"Freeman, Tim" <tim.freeman@hp.com> Thu, 09 September 2010 03:05 UTC

Return-Path: <tim.freeman@hp.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 5323B3A6838 for <oauth@core3.amsl.com>; Wed, 8 Sep 2010 20:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fphr5-hci4wQ for <oauth@core3.amsl.com>; Wed, 8 Sep 2010 20:05:34 -0700 (PDT)
Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 374573A67E1 for <oauth@ietf.org>; Wed, 8 Sep 2010 20:05:34 -0700 (PDT)
Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C327C8921 for <oauth@ietf.org>; Thu, 9 Sep 2010 03:06:01 +0000 (UTC)
Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 9 Sep 2010 03:04:49 +0000
Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Thu, 9 Sep 2010 03:04:40 +0000
From: "Freeman, Tim" <tim.freeman@hp.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 09 Sep 2010 03:04:37 +0000
Thread-Topic: Why give the redirect URI when trading an access code for an access token?
Thread-Index: ActPy7z55fqeLYGoQ5ugjINJWPMP0w==
Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532547F10@GVW0432EXB.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: BT4L CIBl Ci96 CtUE EH/P FJdl FUAf FZtl Fhle Fhpv F5JQ HBFo HJT1 H/xt IP5r ImG7; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {57286824-E924-4D60-8531-2C3584BE3AC0}; dABpAG0ALgBmAHIAZQBlAG0AYQBuAEAAaABwAC4AYwBvAG0A; Thu, 09 Sep 2010 03:04:37 GMT; VwBoAHkAIABnAGkAdgBlACAAdABoAGUAIAByAGUAZABpAHIAZQBjAHQAIABVAFIASQAgAHcAaABlAG4AIAB0AHIAYQBkAGkAbgBnACAAYQBuACAAYQBjAGMAZQBzAHMAIABjAG8AZABlACAAZgBvAHIAIABhAG4AIABhAGMAYwBlAHMAcwAgAHQAbwBrAGUAbgA/AA==
x-cr-puzzleid: {57286824-E924-4D60-8531-2C3584BE3AC0}
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token?
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, 09 Sep 2010 03:09:26 -0000

Hi.  I'm new here.  I searched the archives a bit and didn't immediately find an answer to my question below.  My apologies if there was some previous discussion of this that I missed.

Looking at the draft spec at http://tools.ietf.org/html/draft-ietf-oauth-v2-10, I see in section 4.1.1 "Authorization code" on page 22 that it is required to give the redirect_uri of the original request when exchanging an authorization code for an access token, and the authorization server must verify that the redirection URI is correct as well as the authorization code.  Based on section 4.2 "Access Token Response" on page 25, it seems that the redirect_uri is not used when constructing the response from the authorization server.

So far as I can tell, the redirect_uri is useless in this request.  It does not contain any secrets.  The authorization code is verified and is meant to be an arbitrary unguessable identifier, so little is gained by verifying the redirect_uri also.  It is not used to construct the reply.  Why is it required?

Tim Freeman
Email: tim.freeman@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536